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Scope 



The present document contains handover requirements and a handover specification for the data that is identified in 
EU Directive 2006/24/EC on Data Retention [1]. The handover requirements from TS 102 656 [2] are derived from the 
requirements contained in and impHed by the EU Directive [1] and by other national legislations. The present document 
considers both the requesting of retained data and the delivery of the results. 

The present document defines an electronic interface. An informative annex describes how this interface may be 
adapted for manual techniques. Apart from in annex I, the present document does not consider manual techniques. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the 
reference document (including any amendments) applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are necessary for the application of the present document. 

[1] Directive 2006/24/EC of the European Parliament and of the Council of 15 March 2006 on the 

retention of data generated or processed in connection with the provision of publicly available 
electronic communications services or of public communications networks and amending 
Directive 2002/58/EC. 

[2] ETSI TS 102 656: "Lawful Interception (LI); Retained Data; Requirements of Law Enforcement 

Agencies for handling Retained Data". 

[3] ETSI TS 102 232-1: "Lawful Interception (LI); Handover Interface and Service-Specific 

Details (SSD) for IP delivery; Part 1: Handover specification for IP delivery". 

[4] ISO 3166-1: "Codes for the representation of names of countries and their subdivisions - 

Part 1: Country codes". 

[5] ISO 4217: "Codes for the representation of currencies and funds". 

[6] ETSI TS 101 671: "Lawful Interception (LI); Handover interface for the lawful interception of 

telecommunications traffic". 

NOTE: Periodically TS 101 671 is published as ES 201 671. A reference to the latest version of the TS as above 
reflects the latest stable content from ETSI/TC LI. 

[7] ETSI EN 300 356 (all parts): "Integrated Services Digital Network (ISDN); Signalling System 

No.7 (SS7); ISDN User Part (ISUP) version 4 for the international interface". 

[8] ETSI TS 100 974: "Digital cellular telecommunications system (Phase 2+); Mobile Application 

Part (MAP) Specification (3GPP TS 09.02)". 

[9] ETSI TS 124 008: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; Mobile radio interface Layer 3 specification; Core 
network protocols; Stage 3 (3GPP TS 24.008)". 

[10] Void. 
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[11] ETSI TS 133 108: "Universal Mobile Telecommunications System (UMTS); LTE; 3G security; 

Handover interface for Lawful Interception (LI) (3GPP TS 33.108)". 

[12] ETSI TS 101 109: "Digital cellular telecommunications system (Phase 2+); Universal 

Geographical Area Description (GAD) (3GPP TS 03.32 version 7.2.0 Release 1998)". 

[13] FIPS PUB 186-2: "Digital Signature Standard (DSS)". 

[14] IETF RFC 2616: "Hypertext Transfer Protocol - HTTP/1.1". 

[15] IETF RFC 2818: "HTTP Over TLS". 

[16] ETSI TS 123 040: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); Technical realization of the Short Message Service (SMS) 
(3GPP TS 23.040)". 

[17] IETF RFC 0793: "Transmission Control Protocol". 

[18] IETF RFC 5681: "TCP Congestion Control". 

NOTE: IETF RFC 568 1 obsoletes IETF RFC 258 1 : "TCP Congestion Control" . 

[19] IETF RFC 6298: "Computing TCP's Retransmission Timer". 

NOTE: IETF RFC 6298 obsoletes IETF RFC 2988: "Computing TCP's Retransmission Timer". 

[20] IETF RFC 1 122: "Requirements for Internet Hosts - Communication Layers". 

[2 1 ] IETF RFC 079 1 : "Internet Protocol" . 

[22] ETSI ES 282 002: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN Emulation Sub-system (PES); Functional 
architecture". 

[23] IETF RFC 0822: "Standard for the format of ARPA internet text messages". 

[24] IETF RFC 5322: "Internet Message Format". 

NOTE: IETF RFC 5322 obsoletes IETF RFC 2822: "Internet Message Format". 

[25] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); LTE; IP Multimedia Subsystem (IMS); 
Stage 2 (3GPPTS 23.228)". 

[26] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[27] IETF RFC 4506: "XDR: External Data Representation Standard" . 

[28] ISO 13616-1:2007: "Financial services - International bank account number (IB AN) - 

Part 1: Structure of the IB AN". 

[29] ISO 9362:2009: "Banking - Banking telecommunication messages - Business identifier 

code (BIC)". 

[30] Void. 

[31] ETSI TS 125 413: "3rd Generation Partnership Project;Technical Specification Group Radio 

Access Network; UTRAN lu interface Radio Access Network Application Part (RANAP) 
signalling (3GPP TS 25.413)". 

2.2 Informative references 

The following referenced documents are not necessary for the application of the present document but they assist the 
user with regard to a particular subject area. 

Not applicable. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

authorized organization: any authority legally authorized to request or receive retained data e.g. a Law Enforcement 
Agency 

Handover Interface A (HI-A): administrative handover interface comprising requests for information and their 
responses 

Handover Interface B (HI-B): data handover interface comprising the retained data transmission of information 

issuing authority: any entity possessing the necessary jurisdiction and authority pursuant to law to compel a service 
provider to deliver retained subscriber information or traffic data specified in a query 

lawful authorization: permission granted to an Authorized Organization under certain conditions to request specified 
telecommunications retained data and requiring co-operation from a network operator/service provider/access provider 

NOTE: Typically, this refers to a warrant or order issued by a lawfully authorized body. 

location information: information relating to the geographic, physical or logical location of an identity relating to an 
interception subject 

number: any address (E.164, IP, email, URI) used for routing in a network or in a service on a user level or 
network/service level 

receiving authority: any entity possessing the necessary authority pursuant to law and the technical means to receive 
retained subscriber information or traffic data delivered by a service provider 

request: legal requirement for a Communications Service Provider (CSP) to disclose retained data in accordance with 
relevant national law 

response to request of information: response from the CSP to the authorized organization acknowledging or rejecting 
a request for information 

retained data record: set of data elements for a specific subscriber/user related to a specific service transaction 

service transaction: instance of a service given by a CSP to a subscriber/user 

service transaction record: set of data elements describing a service transaction (details to be determined) 

transmission of information: transmission of retained data from the CSP to the receiving authority 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ACK Acknowledge 

ADSL Asymmetric Digital Subscriber Line 

AO Authorized Organization 

APN Access Point Name 

ASCII American Standard Code for Information Interchange 

ASN Abstract Syntax Notation 

BER Basic Encoding Rules 

BIC Business Identifier Code 

CPE Customer Premises Equipment 

CS Circuit Switched 

CSP Communications Service Provider 

CSPID CSP Identifier 

DNS Domain Name System 
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DR Data Retention 

DRD Data Retention Directive 

DSA Digital Signature Algorithm 

DSL Digital Subscriber Line 

DSS Digital Signature Standard 

DVD Digital Versatile Disc or Digital Video Disc 

EMS Enhanced Messaging Service 

GGSN Gateway GPRS Support Node 

GPRS General Packet Radio Service 

GSM Global System for Mobile communications 

HI Handover Interface 

HI-A Handover Interface A 

HI-B Handover Interface B 

HTTP HyperText Transfer Protocol 

HTTPS HyperText Transfer Protocol over Secure Socket Layer 

IRAN International Banking Account Number 

ICCID Integrated Circuit Card ID 

ID IDentifier 

lEI Information Element Identifier 

IMAP Internet Message Access Protocol 

IMEI International Mobile Equipment Identity 

IMS IP Multimedia Subsystem 

IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

IPSec Internet Protocol Security 

IRI Intercept Related Information 

ISDN Integrated Services Digital Network 

ISUP ISDN User Part 

LAN Local Area Network 

LEA Law Enforcement Agency 

LI Lawful Interception 

MAC Media Access Control 

MF-B Mediation Function B 

MMS Multimedia Messaging Service 

MS Mobile Station 

MSC Mobile Switching Centre 

MSISDN Mobile Subscriber ISDN number 

MSN Multiple Subscriber Number 

NA Network Access 

NAS Network Access Server 

PDP Packet Data Protocol 

PDU Protocol Data Unit 

PS Packet Switched 

PSTN Public Switched Telephone Network 

PUK Personal Unblocking Key 

RAI Routing Area Identifier 

RD Retained Data 

RDHI Retained Data Handover Interface 

SAI Service Area Identifier 

SC SMS Centre 

SDP Session Description Protocol 

SGSN Serving GPRS Support Node 

SHA Secure Hash Algorithm 

SIM Subscriber Identity Module 

SIP Session Initiation Protocol 

SMS Short Message Service 

SMTP Simple Mail Transfer Protocol 

TCP Transmission Control Protocol 

TL Latency Time 

TLS Transport Layer Security 

TR Time of the Request 

TV Television 
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UMTS 

URI 

UTF 

UTM 

WGS 

XML 



Universal Mobile Telecommunication System 
Uniform Resource Identifier 
Unicode Transformation Format 
Universal Transverse Mercator 
World Geodetic System 
extensible Markup Language 



Overview of handover interface 



4.1 



Reference model 



The generic Handover Interface adopts a two-port structure such that administrative request/response information 
(HI- A) and Retained Data Information (HI-B) are logically separated. 

Figure 1 is the reference model for the request and transmission of retained telecommunications data. 



CSP 


Handover interface HI-A: 
administrative 


Handover interface HI-B: 
transmission df RD material 


W 



Authorized 
Organization 



NOTE 1 : The term Authorized Organization covers any agency legally authorized to make RDHI requests 

(see clause 3.1). 
NOTE 2: HI-B delivers data from CSP to the Authorized Organization. There may be related supporting lower level 

messages from the Authorized Organization to CSP on HI-B. 

Figure 1 : Functional diagram showing handover interface IHi 

Each of these two parties can be expanded to show some of their internal functions. This is not to proscribe how 
implementations of the present document must be organized, and is purely informational. 

Within the CSP block, three internal CSP functions can be identified: an administrative function to manage the RD 
requests and responses; a data collection function to collect data from the various internal network elements and prepare 
the data for retention; a data store management function to index and store the data, execute queries, and manage the 
maximum retention period for RD. 

Within the Authorized Organization block, two functions can be identified: an issuing authority responsible for 
initiating new RDHI requests; a receiving authority to accept the RDHI responses. In many situations, the authority 
issuing a request will also be the authority to receive the responses. However, the issuing authority may indicate a 
different delivery point for HI-B responses, in which case the issuing authority and receiving authority will be different. 

These internal functions, and the interfaces between them, do not form a normative part of the present document. 
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CSP 



Authorized Organization 




Data 
collection 




Administrative 
function 


function 




i L 




1 


r 








Data store 

management 

function 





HI-A 

•^ ► 



HI-B 



Issuing Authority 



Receiving Authority 



Figure 2: Functional model (informative) 

A CSP or Authorized Organization may outsource some of its internal functions to a third party. It is a national option 
whether or not outsourcing is allowed, or whether conditions apply. 

4.2 Structure of document and applicable communication 
domains 

The present document defines a framework that applies to all Retained Data. The present document defines a range of 
services (as shown in figure 3). The present document contains one annex for each service (annex B onwards). 




Telephony 
services 



Asynchronous 
message 
services 



Synchronous 

Multi-media 

services 



Network 
access 



Other 
services - 
for further 

study 



Figure 3: Framework structure 

The framework defines the message procedures, the identifying and header information for each message, data 
exchange techniques, and security measures. Each service-specific annex defines the information that is available 
within that particular service. 

The present document does not mandate or require CSPs to create data by inspecting or analyzing communication 
content. 

The scope of each service is as follows: 

• Telephony services covers those services offering the facilities listed in clause B.l. It covers services that 
provides PSTN/ISDN functionaUty (either offered over PSTN/ISDN or emulated PSTN/ISDN (as defined in 
ES 282 002 [22]) over IP) including GSM/UMTS-CS, SMS and MMS. 

NOTE 1: EMS (3GPP TS 23.040 [16]) is handled as SMS. 
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Asynchronous messaging services covers asynchronous communications involving the intermediate storage of 
messages, as defined in clause C.l. This includes e-mail, webmail but excludes chat, which is synchronous, 
and excludes SMS and MMS. 

Synchronous multimedia services are covered by the present document. Specifically, the present document 
contains details for interactive or synchronous communication sessions beyond the telephony services. 

Network access services covers the services offering a capability to access public data networks (typically the 
internet), including GPRS/UMTS-PS, as defined in clause E.l. 



NOTE 2: Data about subscriber are common to all services, as shown in the type declaration 

GenericSubscriberlnfo. Even if the interface specification includes a copy of subscriber records 
embedded within each type of service, these records may be stored in just one copy in the Retained Data 
repository on the operator side and with references to/from the subscribed-to services in order to reduce 
storage size. 

The present document is extensible: additional services may be added in future. 

4.3 Categories of retained data 

Retained data is broken down into the following categories: 

Subscriber data: information relating to a subscription to a particular service (e.g. Name, Address). 

Usage data: information relating to usage of a particular service (e.g. Call Records). 

Equipment data: information relating to an end-user device or handset. 

Network element data: information relating to a component in the underlying network infrastructure 

(e.g. location and identifier of a GSM base station) (for example, if this is not available from the usage data). 

Billing data: information relating to a subscriber's billing details and history. 

A more detailed breakdown for some of these categories is given in annex H. 

Each service shall break down its information into the categories listed above. There shall be no information outside of 
the above categories. For certain services, particular categories may not apply. 

Future categories may be added a later date. 

4.4 Handover Interface port 1 (Hl-A) and Handover Interface 
port2(HI-B) 

The Handover Interface port 1 (HI- A) shall transport request, cancel and error information from/to the Authorized 
Organization and the organization at the CSP, which is responsible for Retained Data matters. 

The Handover Interface port 2 (HI-B) shall be used for all communication (retained data information, response, status 
and error messages) between the CSP to the Authorized Organization. 

For a complete assignment of communication types to the handover Interface ports see clause 5.4. 

The HI-A and HI-B interfaces may be crossing borders between countries. This possibility is subject to corresponding 
national law and/or international agreements. 
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Figure 4: RDHI model 



Handover interface message flows 



5.1 



Introduction 



5.1.1 Summary of this clause 

Clause 5 identifies the messages that shall be sent over the RDHI. 

The following situations are covered (see clause 5.1.3): successful deliveries, cancelled deliveries, basic error situations 
and the delivery of results in stages. 

The RDHI can operate in one of two modes (see clause 5.1.2). Clause 5.1 applies to both modes. Clause 5.2 covers the 
General mode, and clause 5.3 covers the Authorized-Organization-initiated mode. 

Clause 5.4 defines the HI-A and HI-B message types. 

Clause 5.5 covers addressing over HI-A and HI-B. 

5.1 .2 Message flow modes 

RDHI message flows are defined for the following two situations: 

• The General situation, where there is a transport mechanism that supports a full two-way transport of 
messages between Authorized Organizations and CSPs (see clause 5.2). 

• The Authorized-Organization-initiated situation, where there is a transport mechanism in which the 
Authorized Organization initiates a communication and then the CSP responds i.e. the CSP is only able to send 
messages in response to an Authorized Organization message (see clause 5.3). 

The remainder of clause 5.1 contains information that applies to both situations. 
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5.1.3 Delivery cases 

Message flows for the following cases are covered: 

• A successful complete delivery. 

• A basic error at the CSP, signalling that no further results will be delivered for that request (see clause 5.1.5). 

• The Authorized Organization cancels a request, signalling that no further results shall be delivered for that 
request (see clause 5.1.6). 

• The delivery of some of the results before all results are ready (see clause 5.1.7). 

5.1 .4 "Active" requests and "closed" requests 

It is essential that both parties are clear about when a request is active (i.e. the CSP is researching the answer) and when 
it is closed (i.e. the CSP is no longer expected to be working on the request). In order to do this, each message flow 
contains the following underlying steps: 

• Authorized Organization submits a request to the CSP. 

• CSP acknowledges it has received the request: 

The request is now said to be "active". 

• Either Authorized Organization or CSP signals to the other party that the request is ended (e.g. all results have 
been sent, an error has occurred). 

• An acknowledgement is sent to confirm receipt of the message that ends the request: 

The request is now said to be "closed". 

NOTE: The acknowledgements are required to be generated at an application level i.e. the CSP or Authorized 
Organization application is confirming receipt of the message. A transport level acknowledgement 
(e.g. TCP ACK) is not sufficient. 

5.1 .5 Errors and failure situations 
5.1 .5.1 Error and failure types 

The present document covers two varieties of mistake or failure: 

1) ResponseFailed: If an Authorized Organization sends a request which the CSP cannot process, then the CSP 
sends a ResponseFailed message (see clause 5.1.5.2). 

2) Errors: If one party makes a syntactical or protocol-level error (e.g. badly-formatted XML or invalid 
authorization), the other party can return an error. The message with the mistake is then ignored (see 
clause 5.1.5.3). 

It is possible that more detail is needed (beyond what is covered by the present document), e.g. it might be the case that 
the Authorized Organization does not consider the "complete" answer from the CSP to be complete. In order to resolve 
these situations, it will be necessary for the Authorized Organization and CSP to discuss the matter person-to-person 
and this is not covered by the present document. Once any problems have been resolved, if the original request is still 
relevant, the request should be re-sent by the Authorized Organization (using a new request number i.e. completely 
independent of the previous request). 
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5.1 .5.2 Request process failure feedback 

If the CSP is unable to process an active request for technical reasons (e.g. authorization not verified, unable internal 
CSP error), then they shall send a response message marked as "FailureResponse" via the HI-B interface. This 
terminates the request and shall be acknowledged. The CSP is required to co-operate in resolving the error and it is 
likely that the request is re-issued (perhaps with some changes); however, from the point of view of the present 
document, all further messages will be handled manually or as a brand new request. 

5.1.5.3 Other errors 

If the CSP receives a message that is incorrectly formatted or out of order in the State diagram then they shall reply with 
an error message. The error message shall indicate, where possible, the request ID that was specified in the "bad" 
message. If the request ID is present in the error message, the Authorized Organization shall consider its previous 
message on that request ID to have been ignored. 

Error messages should, if appropriate, include a short description of the error. There is no concept of an error 
acknowledgement for this sort of error. 

Error messages shall always be sent via the interface where the original message causing the error initiated. So for 
example an error message responding to a broken request shall be sent via HI-A whereas an error message responding 
to a bad getResult message shall be sent via the HI-B interface. 

5.1.5.4 Missing messages 

Both the CSP and the Authorized Organization may at times be waiting for a message from the other party. It is an error 
for that message never to arrive, and the CSP and Authorized Organization must take appropriate action to resolve the 
error situation. 

This error differs from transmission errors at the transport level. Transport layer protocols (see clause 7) take care of 
transmission errors, and present a reliable end to end channel to their parties. However, even assuming a perfect 
transmission channel, messages may be lost due to issues in higher protocol levels. The CSP and Authorized 
Organization must gracefully handle these situations. 

There are two strategies that can be used to resolve missing messages: wait or raise a timeout indication to local 
operators. The timeout periods for waiting are a national issue. These periods may depend on the priority of the request 
(see clause 6.3.3.1) or the suggested completion time (see clause A.2.2.2). 

The CSP could use the following strategies: 

• Waiting for a Request message: 
the CSP should wait indefinitely. 

• Waiting for a GetResults message (Authorized-Organization-initiated scenario only): 

the CSP should wait for at most tpMedium for a message to arrive, then raise a timeout indication. 

• Waiting for a GetStatus or Cancel message (Authorized-Organization-initiated scenario only): 

the CSP should wait for at most tpLong for either message to arrive, then raise a timeout indication. 

• Waiting for a Response Acknowledgment message: 

the CSP should wait for tpMedium, then raise a timeout indication. 

The Authorized Organization could use the following strategies: 

• Waiting for a Request Acknowledgement message: 

the AO should wait for at most tpMedium, then raise a timeout indication. 

• Waiting for a Response message (general scenario only): 

the AO should wait for at most tpLong, then raise a timeout indication. 

• Waiting for a Response message (Authorized-Organization-initiated scenario only): 
the AO should wait for at most tpMedium, then raise a timeout indication. 

• Waiting for Status or Cancel Acknowledgement message: 

the AO should wait for at most tpShort, then raise a timeout indication. 
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NOTE 1 : When no manual interventions are required after the initial request (when handling of DR requests is fully 
automated), the following approximate timeout periods are suggested. tpShort: a few minutes to an hour; 
tpMedium: tens of minutes to a few hours; tpLong: a few days. 

NOTE 2: When manual interventions are necessary during the handling of a request, the timeout behaviour should 
be agreed upon by the Authorized Organisation and the CSP on a national basis. One option may be to 
always wait indefinitely, and raise fatal timeout indications manually when necessary. 

5.1 .6 Cancelling a request 

The Authorized Organization may cancel any of its own active requests (as described in clauses 5.2.2 or 5.3.2), to signal 
that no further processing or delivery shall take place against that request. 

Failure to comply with an otherwise syntactically correct cancellation (e.g. cancelling somebody else's request) shall 
also be indicated by an error message. 

Only "active" requests may be cancelled, see clause 5.1.4. 

5.1 .7 Delivery of results 

By default, a single shot delivery approach shall be used. This means that the CSP gathers all the results meeting the 
request, and then they are delivered together with an indication that the results are "complete". This is acknowledged by 
the Authorized Organization and the request is closed. 

Subject to national agreement, a multi-part delivery approach may be used. This means that results are delivered in a 
number of batches. The present document does not define the criteria which cause a batch of records to be sent (they 
may include: "after a certain time has elapsed", "once a certain number of records have been gathered", or may be based 
on other criteria); such criteria are agreed in advance outside of the message flows in the present document. Unless the 
CSP is certain that all results have been sent, it shall indicate that a batch of results is "incomplete"; such deliveries shall 
be acknowledged by the Authorized Organization as described in clauses 5.2.3 and 5.3.3, and the request remains 
active. Once the CSP is certain that there are no more results, it shall indicate that the results are "complete"; the 
Authorized Organization shall acknowledge this and the request is closed. 

NOTE 1: The use of multi-part delivery is not to take place without permission in advance from the Authorized 
Organization concerned. In some situations, multi-part delivery creates additional complications at the 
CSP; the use of multi-part delivery is to take into account its technical feasibility at the CSP side. 

NOTE 2: A CSP is considered to be certain that the result is complete if the data available in its own domain for the 
requested period has been sent. It is a national issue to deal with data received by the CSP from outside its 
domain after a "complete" message has been sent. 
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5.1.8 State diagram 



The messages described in clauses 5.2 and 5.3 follow this state diagram in figure 5. 

Error messages are not shown in figure 5. The error message (and the message that contains the error) cause no change 
in state. 
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Figure 5: State diagram 
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The GetStatus message in clause 5.3 follows this state diagram in figure 6, independent of the state of each request. 
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Figure 6: State diagram for GetStatus 



5.1 .9 Supplementary Messages 



Two extra messages are provided to allow national jurisdictions to re-use the RDHI transport and session mechanisms 
for auxiliary RDHI-related functions. The two messages are: 

• SupplementaryRequest; 

• SupplementaryResponse. 

These two messages define a simple request-response pair. The current document does not define any specific auxiliary 
functions or behaviours that may be mediated by these messages. Such definitions are left to national jurisdictions. 

The SupplementaryRequest message is issued by an RDHI Client wishing to exercise a nationally defined auxiliary 
RDHI function. 

If the RDHI Server receiving the SupplementaryRequest message can understand and accept the request, it responds 
with a SupplementaryResponse message. If the Server does not understand the message, it shall respond with an RDHI 
Error message. 

The exchange of Supplementary Messages does not affect the existing RDHI state machine in any way. Exisiting RDHI 
behaviours and semantics are unaffected. 

5.2 Message flows for general situation 
5.2.1 Delivery of a response 

The following stages constitute the delivery of a response: 

• Request message (Req): 

The Authorized Organization sends a request for RD information. 

• Request acknowledgement (ReqAck): 

Without undue delay, the CSP acknowledges it has received a message from the Authorized Organization. The 
CSP is now under obligation to work on the given request and the request is active. 
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The CSP assembles a set of information that it beheves to be a complete response (i.e. fully meets its 
obligation), and it is delivered over HI-B as a Res message: 

If there are no records meeting the request criteria, a response shall still be sent, containing zero records. 
The Res message will have the "responseComplete" flag set. 

If the request cannot be fulfilled for technical or procedural reasons (e.g. request exceeds authentication, 
or an internal CSP error), the Res message has the "responseFailed" flag set. This should contain details 
of why the request is unserviceable. 

Response acknowledgement (ResAck): 

Without undue delay, the Authorized Organization acknowledges it has received a Res message from the CSP. 
The CSP is now no longer under obligation to do further work on the given request and the request is closed 
(i.e. no longer active). 



CSP 

Req: Request for RD 
(HI-A) 



Authorized Organization 



Req(Ack): Acknowledge request 
(HI-A) 



Res: Send results 
LHI-Bi 



Res(Ack): Acknowledge Res message 
(HI-B) 



Figure 7: Message flow Successful delivery 

5.2.2 Cancellation of request 

Cancellation is an optional function and works as follows: 

• Cancel: 

For any active request, the Authorized Organization may issue a Cancel message. 

• Cancel acknowledgement (CancelAck): 

Without undue delay, the CSP acknowledges it has received the Cancel message. The CSP is now no longer 
under an obligation to do further work on the given request and the request is no longer "active". 

• Cancel rejection. 

• The cancel messages after an already fully answered request will cause an error message to be returned 

(see clause 5.1.5.3). Similarly, authorization failures (when one Authorized Organization attempts to cancel a 
request that was submitted by a different Authorized Organization) shall cause an error message. The CSP 
may choose to create an alarm in this situation (the alarm is not part of the handover interface). 

If the optional function multi-part delivery is used, it is acceptable to send a Cancel message after some of the results 
have been received. After a Cancel message, no further results shall be sent, and a Cancel Acknowledgement shall be 
used. 
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Figure 8: Message flow Cancellation by Authorized Organization 



5.2.3 Multi-part delivery 



As stated in clause 5.1.7, multi-part deliveries (including the sequential/parallel delivery option) are a national option, 
only to be used by agreement at a national level. 

Multi-part deliveries are made as follows: 

• Request is made and acknowledged as usual over HI-A. 

• Incomplete sets of results are sent over HI-B according to agreed criteria (see clause 5.1.7). Each is flagged as 
"responselncomplete". 

• The Authorized Organization acknowledges each incomplete results message with a ResInc(Ack) message 
(this is a Res(Ack) message with type set to "AcknowledgelncompleteResults"). 

NOTE: Partial results should also be acknowledged. It is important to the CSP, for legal reasons, that the 

Authorized Organization confirms that results were received. Such an acknowledgement does not imply 
that the CSP has fulfilled all of its obligations. 

• The last set of results is flagged as "responseComplete" to indicate there will not be any further results to 
come. "Complete" means all data that was available for transmitting has been transmitted. 

For multi-part delivery of the result over HI-B there are two possible options: 

Sequential delivery requires that there shall be no next partial delivery until the ACK has been received. 

Parallel delivery allows the CSP to transmit multiple results messages where each results message is 
separately acknowledged without needing to wait for an ACK for other related results message(s). For 
parallel delivery, each results message shall have a response number starting at 1 and being incremented 
for each response message. The ACK message for a given results message has to include the response 
number of the message which it acknowledges. 

• The Authorized Organization acknowledges the final results message with a Res(Ack) message. 
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Figure 9: Message flow multi-part delivery 

5.3 Message flows for Authorized-Organization-initiated 
scenario 



5.3.1 Delivery of results or a failure response 

The following messages are sent: 

• Request and acknowledge: 

Request message (Req): 

The Authorized Organization sends a request for RD information. 

Request acknowledgement (ReqAck): 

Without undue delay, the CSP acknowledges it has received a message from the Authorized 

Organization. The CSP is now under obligation to work on the given request and the request is said to be 

"active". 

• Status messages (the use of Status Messages is optional, for discussion on a national basis): 

The Authorized Organization sends a GetStatusMessage request to the CSP. This message contains a list 
of RequestlDs for which the Authorized Organization requires status information. An Authorized 
Organization shall only make status requests about its own requests, not those from other Authorized 
Organizations. 

Upon receiving the GetStatusMessage, the CSP sends a StatusMessage containing a collection of 
StatusResponses, one for each of the relevant RequestlDs. The StatusResponse for each RequestID 
contains a status flag which may be one of the values listed below. The GetStatus and Status messages 
do not change the status of any request, they only report on it: 

ready - the records are ready to be collected by the Authorized Organization; 

incompleteResultsReady - see clause 5.3.3; 

notReady - the records are not yet ready for collection; 

failureResponseReady - the request has failed. The Authorized Organization should issue a 
GetResults to find further details; 

inDelivery - the records are currently being sent to the Authorized Organization; 
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■ invalidRequestID - no such request is outstanding. 
• Results messages: 

GetResults message: 

If there are resuhs ready to be collected, the Authorized Organization sends a GetResults message to a 

CSP on HI-B, to initiate the delivery of results for a specific request ID. 

NOTE 1 : The Authorized Organization is expected to collect results reasonably promptly as soon as it is indicated 
they are ready. 

The CSP shall respond with a Res message on HI-B, giving the results for the request ID in question. If 
the response has failed (as described in clause 5.1.5.2) then the response will have the responseFailed 
flag set, and further details are included. If the results are not yet available, then the response will have 
the responseUnavailable flag set. 

NOTE 2: An Authorized Organization should not make another GetResults request against a request ID until it has 
received reply to a previous one, or a predetermined time has passed. 

If a Res message has been sent by the CSP, the Authorized Organization shall send a Res(Ack) without 
undue delay, and the request will no longer be active. 
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Req: Request for RD 
(HI-AI 



Req(Ack): Acknowledge request 
(HI-A) 



GetStatus: request the status of specified req uests. 
(HI-B) 
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Res: send results 
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Res(Ack): Acknowledge Res message 
(HI-B) 



Figure 10: Delivery of results as initiated by the Authorized Organization 

5.3.2 Cancellation of request 

Exactly the same as clause 5.2.2. 

5.3.3 Multi-part delivery 

As stated in clause 5.1.7, multi-part deliveries are a national option, only to be used by agreement at a national level. 
Multi-part messages work as follows: 

• Request is made and acknowledged as usual. 
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If a batch of responses is ready to send, then the CSP responds to a GetStatus message with the value 
"Incomplete results ready". As described in clause 5.1.7, the criteria for when such a batch is ready are outside 
the scope of the present document. 

The Authorized Organization may issue a getResults against a request that has been marked as "Incomplete 
results ready". 

The CSP shall return a response message containing the batch of responses. It is flagged as 
"Resultslncomplete" . 

The Authorized Organization shall acknowledge each incomplete results message with a ResInc(Ack) message 
(this is a Res(Ack) message with type set to "AcknowledgelncompleteResults"). 

While the CSP is waiting to collate the next batch of responses, it answers a GetStatus messages with a value 
of"notReady". 

When the next batch is ready, the status becomes "Ready" (for the final batch) or "IncompleteResultsReady" 
(for an incomplete set). 

The final batch of responses is flagged as "ResultsComplete". The Authorized Organization acknowledges the 
final results with a Res(Ack) message. 
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Figure 1 1 : Delivery of results as initiated by the authorized organization 
in case of multi-part delivery 

5.4 Message types for HI-A and HI-B 

In the functional model (figure 2) the CSP communicates with the Issuing Authority using handover interface port A 
only, and the MF-B communicates with the Receiving Authority using handover interface port B only. The Issuing 
Authority and the Receiving Authority are functional entities. National regulations may choose to combine Issuing and 
Receiving Authorities. 

Table 1 shows whether each message shall be sent as HI-A or HI-B. 
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Table 1 : Message types that can be sent via Hl-A and Hl-B 



Message 


Hl-A 


Hl-B 


Remarks 


requestMessage 


X 






requestAcknowledgement 


X 






getResultsMessage 




X 




responseMessage (Complete) 




X 




responseMessage (Incomplete) 




X 




responseMessage (Unavailable) 




X 




responseMessage (Failed) 




X 




responseAcknowledgement 




X 




cancelMessage 


X 






cancelAcknowledgement 


X 






getstatusMessage 




X 




statusMessage 




X 




errorMessage 


X 


X 


Always sent via the same port as the request 
being responded to. 



5.5 Hl-A and Hl-B addressing 



The Authorized Organization and the CSP can use multiple addresses for messages sent over HI-A and HI-B. The set of 
addresses used must be prearranged between the Authorized Organization and the CSP. The messages in clause 6 can 
contain delivery points. These are used to avoid mentioning specific addresses. 

When the Authorized Organization initiates any kind of request, the CSP must return the corresponding 
acknowledgement and/or response to the address from which the request originated. However, when submitting an 
RDHI request, the Authorized Organization can indicate a different delivery point to which HI-B data must be sent. If 
no explicit delivery point is specified, the HI-B responses must be sent to the point from which the RDHI request 
originated. 



Definition of the elements for retained data 
messages 



6.1 



Header information 



6.1 .1 Use of header information 

All of the information in clause 6.1 is required on all messages unless stated otherwise. 

6.1 .2 RequestID field specification 

Each message shall have a RequestID. The RequestID distinguishes that request from any other on an international 
level. To do this, the RequestID shall contain: 

• a country code (to indicate the country of the body making the request); 

• an Authorized Organization code (assignable within the given country to distinguish between different 
Authorized Organizations); 

• a unique reference number (assignable by the Authorized Organization). Authorized Organizations will need 
to ensure they have warrants or other authorization held against each request reference number. For a 
GetstatusMessage or StatusMessage the reference number shall not be present in the RequestID (instead there 
is a list of reference numbers in the body of the message). 
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6.1.3 CSP Identifiers 

6.1 .3.1 Use of CSP identifiers (CSPID) 

A CSP ID shall be agreed on a national basis. CSP IDs shall not be repeated within the same country (i.e. shall not be 
repeated within the same country code, as given in the request ID). The Authorized Organization and CSP shall agree a 
CSPID before any RDHI requests are made. Each request shall contain the CSP ID. If a CSP receives a request which 
does not have their own CSPID, they shall signal an error (see clause 5.1.5). The CSP ID shall be included in all further 
HI-A and HI-B messages. 

NOTE 1 : It is not a NetworkElement ID and does not refer to exactly where in any network the info came from. 

NOTE 2: If there is already a scheme of identifiers defined that is unique for CSPs in a given country, it is 
recommended that this is re-used. 

6.1 .3.2 Third Party CSP Identifier (thirdPartyCSPID) 

Where a CSP is holding data on behalf of another CSP, the thirdPartyCSPID shall be used to indicate that an 
Authorized Organization is making a Retained Data Request over the HI- An interface, relating to a third party CSPs for 
which the CSP specified in the CSPID field is retaining data. Similarly a CSP disclosing data over the HI-B interface 
shall use the thirdPartyCSPID field to indicate that the data being disclosed does not relate to a subscriber owned by the 
CSP specified in the CSPID field. 

The thirdPartyCSPID shall be agreed on a national basis and shall follow the same rules and format as for the CSPID 
field. 

The thirdPartyCSPID is an OPTIONAL parameter. However the thirdPartyCSPID shall be included in all HI-A and 
HI-B messages where the initial Authorized Organization Retained Data request message specified a thirdPartyCSPID. 

If a thirdPartyCSPID is included in the Retained Data Request, the CSP specified in the CSPID field shall only disclose 
data relating to that thirdPartyCSPID and not any other data it holds (e.g. Data specifically belonging to the CSP 
specified in the CSPID field) or any other thirdPartyCSPID. 

6.1 .4 Timestamp (timeStamp) 

The time the message was created shall be included in the message. 

All timestamps shall contain the time and date, and an indication of the time zone. 

6.2 Retained Data response 
6.2.1 General 

The response is a set of records that meet the request criteria. 

The response will be a "flat" sequence with no additional structure to them (e.g. not a "tree" of information in which 
certain records refer back to other records within the same response). 

The records in a response will all be from the same "service" (see clause 4.2) and from the same "category" 
(see clause 4.3). 
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6.2.2 Additional information in response messages 

6.2.2.1 Record number (recordNumber) 

Each retained data record delivered against a particular Req shall be given a record number. The record number shall 
start at and shall increment for each record delivered against the original Req. The record number counts 
independently even if the results are sent in a number of responses (see clause 5.1.7). 

NOTE: The combination of Request ID and record number gives a particular record a globally unique number. 

6.2.2.2 Response status (ResponseStatus) 

Every response shall have a ResponseStatus. The response status will define whether it is complete or incomplete (see 
clause 5.1.7). In addition, for Authorized-Organization-initiated situations, it is possible to indicate a status of 
Unavailable (see clause 5.3.1). 

In case of a request that cannot be fulfilled by CSP for technical or procedural reasons (see clause 5.2.1), it is possible to 
indicate a status of failed response. This is always indicated via the HI-B interface. 

6.2.3 Volatile information 

Certain information changes over time and is called volatile (e.g. Cell IDs are volatile whereas latitude/longitude is not). 
Volatile information shall have a time associated with it, indicating the time of the observation. 

1) The present document supports the transmission of "translated" data i.e. the volatile information converted into 
a permanent form. 

2) The present document supports the querying of historical data, asking what the value of the volatile data was at 
a given time. 

It is a national issue to agree which method(s) to use. It is mandatory that the value of volatile data can be ascertained 
by the Authorized Organization. 

If a request is made for volatile information over a range of times (rather than just a specific time) then the response 
may contain multiple records that match the request. All record falling within the time period shall be sent. 

6.2.4 Unavailable parameters 

If parameters are not able to be filled in by the CSP, the parameter shall be left out. 

There may be scenarios where an Authorized Organization requires parameters that are not available at the CSP 
(e.g. local loop unbundling, where the information is owned by another CSP and is therefore outside the control of the 
CSP to which the request was sent). In these scenarios, the CSP is not obliged to communicate with any other CSP to 
fetch information that they do not own. However, where the CSP has additional information that would assist the 
Authorized Organization, this should be communicated in the additionallnformation parameter. 

A CSP may omit fields in the response for which data is held by another CSP. The format of the additionallnformation 
field is left to national implementation. CSPs and Authorized Organizations should agree beforehand on the format and 
wording of the information returned in these circumstances. 

6.3 Retained Data requests 

6.3.1 Information contained within a request 

A request for retained data, along with the headers defined in clause 6.1, shall consist of a set of query records 
containing request criteria. A request may only ask for data from one service (see clause 4.2) and one category 
(see clause 4.3). For enquiries across multiple services or categories, a request shall be sent for each service and 
category. 

The request shall list one or more request criteria. Each request criteria shall be one of the following types: 
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• EqualTo: A specified value for a given field. 

• NotEqualTo: A specified value which for a given field shall not be equal to. 
NOTE: The NotEqualTo criterion is likely to be used as an additional criterion. 

• Range: A range for a given field (e.g. lower and upper bounds, using the lessThan or greaterThan operators). 

• Member of: A list of values for a given field. 

The CSP shall return all records from the stated service and category that match all of the listed criteria. 

EXAMPLE: A query record of type telephonyServiceUsage with the parameter partyNumber filled in with a 
specific phone number and communicationTime between Tl and T2 will return all 
telephonyServiceUsage records which contain that phone number and communicationTime in the 
interval Tl to T2. 

Annex G gives examples of how common use-cases can be expressed using this formalism. 

6.3.2 Format of a request 

A request message shall contain a full set of valid header information, as defined in clause 6.1. 

A request message shall contain a sequence of criteria, as described in clause 6.3.1. Each criterion shall be expressed as 
a RequestConstraint parameter. The RequestConstraint parameter contains a RetainedDataRecord (or a sequence of 
RetainedDataRecords in the case of IsAMemberOf), specifying a field and a value. The choice of RequestConstraint 
parameter defines the type of criteria, and will be one of the following: 

Equals: The value of the specified field of returned records shall equal the value given. 

NotEqualTo: The value of the specified field of returned records shall not equal the value given. 

NOTE 1 : The NotEqualTo criterion is likely to be used as an additional criterion. 

LessThan: The value of the specified field of returned records shall be less than the value given. Only valid for 
numeric types such as GeneralizedTime or Integer. 

LessThanOrEqualTo: The value of the specified field of returned records shall be less than or equal to the 
value given. Only valid for numeric types such as GeneralizedTime or Integer. 

GreaterThan: The value of the specified field of returned records shall be greater than the value given. Only 
valid for numeric types such as GeneralizedTime or Integer. 

GreaterThanOrEqualTo: The value of the specified field of returned records shall be greater than or equal to 
the value given. Only valid for numeric types such as GeneralizedTime or Integer. 

Starts With: The value of the specified field of returned records shall start with the value given. Only valid for 
string types such as UTFSString. 

EndsWith: The value of the specified field of returned records shall end with the value given. Only valid for 
string types such as UTFSString. 

IsAMemberOf: The value of the specified field of returned records must be equal to one of the values given. 
The different permissible values are given as a sequence of RetainedDataRecords, each with a different 
permissible value set in the field of interest. 

Multiple RequestConstraints of the same type shall be put in the same RetainedDataRecord to indicate multiple criteria. 
Values for all of the criteria must be from the same service and category (see clause 6.3.1). All records from this service 
and category which satisfy all criteria shall be returned. 
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NOTE 2: When using the Is AMemberOf constraint one needs to specify a RetainedDataRecord for each set of 

fields to be used. For example: in order to query about all records of calls which happened to be in either 
of the cells in the group: {celll, cell2}, and be made by either of the phone numbers in the group: 
{phonel, phone2, phone3}, then it will need six instances of RetainedDataRecord in the SEQUENCE of 
the IsAMemberOf constraint. These six instances will be as follows: {celll and phonel}, {celll and 
phone2}, {celll andphone3}, { cell2 and phone 1 } , {cell2 and phone2}, {cell2 and phone3}. In effect 
these instances are a decomposition of the outer product of the two sets. 

6.3.3 Additional information in requests 

6.3.3.1 Priority of a request 

In some situations it may be useful to signal a priority with a request. This is for use at a national level. The present 
document makes no statement about how to treat requests of a different priority, how to manage queues of requests or 
how to manage the use of priority considerations. 

6.3.3.2 Maximum hits 

A request may specify an upper bound on the number of results, by populating the MaxHits parameter in the request. 

It is a national issue to discuss details of how MaxHits are used, and what further action to take when MaxHits is 
exceeded. It is a national issue to discuss how to handle MaxHits with partial deliveries. 

If the MaxHits parameter is present, and if the CSP identifies more results meeting the request than the MaxHits value, 
then the CSP shall treat this as a ResponseFailed (i.e. send a ResponseMessage with ResponseStatus set to 
responsePailed) with the string "Maximum hits exceeded" in the information field of the Furtherlnformation structure. 



6.4 Error messages 



The error message shall contain a textual message giving as many details as possible of the error, and contact details (if 
appropriate) for a person who will be able to assist in resolving the error (see clause 5.1.5.3). 



Data exchange techniques 



7.1 General 

Two data exchange techniques are presented: "HTTP" and "direct TCP". The choice of technique is a national option. 

The data exchange techniques for HI-A and HI-B may be different. For instance XML encoding may be used for HI- A, 
while ASN.l BER encoding may be used for HI-B. This is a matter for agreement between CSP and Authorized 
Organization on case-by-case basis. 
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7.2 HTTP data exchange 

7.2.1 Basic configuration 

The HTTP data exchange technique uses XML encoding. It uses HTTP [14] (on top of the standard TCP/IP stack). 
The HTTP data exchange can be configured as a: 

• single client/server configuration; 

• mutual client/server configuration. 

In a single client/server configuration the initial initiative for data exchange shall be taken by the party with the client. 
In the mutual client/server configuration both parties can take the initiative to exchange data. 

7.2.2 Single client/server 

In the single client/server configuration the CSP runs a HTTP server, and the Authorized Organization acts a HTTP 
client. The HTTP technique is intended to be used with the Authorized-Organization-initiated message flows in 
clause 5.3. The details in clause 7.2.4 also apply to the single client/server model. 

The Authorized Organization and CSP shall agree on a common URI format. A single URI shall be used for all HTTP 
requests. 

7.2.3 Mutual client/server 

In the mutual client/server configuration both CSP and Authorized Organization run a HTTP server and both CSP and 
Authorized Organization act as a HTTP client. The HTTP technique is intended to be used with the general message 
flows in clause 5.2. The details in clause 7.2.4 also apply to the mutual client/server model. 

The Authorized Organization and CSP shall agree on a common URI format. The URIs used for the data exchange shall 
be agreed. 

7.2.4 Details common to both single and mutual cases 

The HTTP specification mentions several mandatory and optional features. Some features can be useful, while others 
raise security concerns. Therefore, the following points should be noted. 

The POST method shall be used for all requests. 

Some HTTP header fields are less useful within the RDHI, or will complicate the handover protocol without adding 
clear benefits. In particular, headers to do with negotiation of content or language, range-limiting of requests, cache 
control, and conditional retrieval should be avoided. The CSP and Authorized Organization shall not send header fields 
unless there is a clear need for those headers. 

Proxies can be useful and may be used. However, caching of whatever form shall not be used. The header 
"Cache-control: no store" may be used to ensure this behaviour. Special care should be taken with the logs kept by 
proxy servers. 

Most requests and responses contain an XML message as their entity-body. Such entity bodies shall specify a content 
type of text/xml. 

It is not acceptable to rely on HTTP status codes as a substitute for RDHI messages. For example, an Authorized 
Organization may not consider a blank HTTP 200 (OK) as a Req(Ack) message; it must also carry a full and 
well-formed RDHI Req(Ack) message as its payload. 

The use of gzip is recommended. 
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7.3 Direct TCP data exchange 



The direct TCP mechanism uses XML, or BER encoding derived from the ASN.l in annex A. The direct TCP option 
uses data exchange details on top of the standard TCP/IP stack. 

The direct TCP technique may be used for both the General message flows (clause 5.2) and the 
Authorised-Organization initiated message flows (clause 5.3). 



7.3.1 Application layer 



When using ASN.l the messages are BER encoded. 

When using XML over TCP the XML messages are transported in a simple packet format, defined as follows: 

struct { 

unsigned int type; 

unsigned hyper length; 

opaque XMLo; 
} XML_Message; 

The definition of the above mentioned fields are defined in table 1 . 

Table 1 : Definition of fields in XML message 



Field name 


Field size (see RFC 4506 [27]) 


Description 


Type 


32 bits 


Type field as defined in table 2 


Length 


64 bits 


Length of the XML data 


XML 


Variable 


"Length" bytes of opaque XML data 



Possible options for the "Type" field are defined in table 2. 

Table 2: Definition of Type values 



Type value 


Meaning 





Invalid / Empty Message 


1 


Plain XML; XML field contains uncompressed XML 


2 


Compressed XML; XML field contains ZLIB compressed XML 


3 - (2'^32 - 1 ) 


Reserved for future use 



7.3.2 Transport layer 



7.3.2.1 



Introduction 



Clause 6.4 of TS 102 232-1 [3] describes a transport layer that is based on the Transport Control Protocol. TCP is 
implemented according to RFC 0793 [17], RFC 5681 [18], RFC 6298 [19] and clause 4.2 of RFC 1122 [20]. According 
to the interface described in clause 4.1 the CSP is the TCP sender and the Authorized Organization is the TCP receiver 
or contrariwise. 



7.3.2.2 



TCP settings 



The source and destination port numbers shall be within the dynamic port range for TCP. The value of the source port 
number is chosen by the TCP sender. The allocation of the destination port number is outside the scope of the present 
document. 

TCP "keep-alive" (RFC 1 122 [20]) should not be used. 
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7.3.3 Network layer 

The Network layer implements the Internet Protocol according to RFC 0791 [21]. 

7.3.4 Delivery networks 

The choice of the network will be made on a national basis for legal and pragmatic reasons. 



8 Security Measures 

8.1 General 

The use of security measures for RDHI is recommended. The following security measures are optional and may be 
adopted (in full or in part) on a national basis. 

The present document makes a distinction between connection level security and application level security. 

NOTE: Connection level security measures are not independent of application level security measures. The 

XML/HTTP ecosystem has certain techniques, measures, and toolkits (for example for digital signatures) 
that have been proven to work together well. 



8.2 Connection Level Security 



The present document considers the electronic interfaces for HI-A and HI-B between the Authorized Organization and 
CSP as connections. Most practical implementations of such secure connections are at the hardware level, and 
sometimes at the software level. For securing these connections the following security measures need to be enforced: 

• Mutual authentication. 

• Confidentiality. 

• Integrity. 

Mutual authentication means that the communicating parties have verified and confirmed each other's identities. 

Confidentiality means that it is impossible to interpret the data by eavesdropping on the communication link. 

Integrity means that any alteration or mutilation of the transported data can be detected. 

ASN.l and XML are used as HI-A and HI-B interface definition languages. For ASN.l the recommended security 
methods are either IPSec or TLS. For XML the recommended security methods are either IPSec or HTTPS 
(RFC 2818 [15]). Whatever method is used, authentication, confidentiality and integrity are to be enforced on these 
connections - for both HI-A and HI-B. 



8.3 Application Level Security 



Connection level security enables a secure means of connection between Authorized Organization and CSP. Such 
measures validate and ensure that on the other side of the link there is a trusted equipment or application belonging to 
the correct entity (Authorized Organization or CSP). However, due to the sensitive nature of retained data, additional 
security measures are recommended at the application level (for both the ASN. 1 and XML methods), similar in some 
respect to the security measures in TS 102 232-1 [3]. 



£75/ 



36 ETSI TS 1 02 657 V1 .1 0.1 (201 2-09) 

The recommended application level security measures are: 

• Digital signature on RDHI requests for HI-A, by an Authorized Organization entity: 

Such an entity might be a person authorizing RDHI requests on HI-A (e.g. an Authorized Organization officer 
or some other person authorized by law or regulation to authorize RDHI requests), or some other entity 
defined by national law or regulation. 

The process involves the Authorized Organization computing a hash over the entire set of fields in the request 
(including the time stamp). Then the hash is digitally signed with the entity's private key. The signed hash and 
the entity's certificate (validating its public key) are sent in the request to the CSP. In effect, the request may be 
viewed as comprising two parts - one part is composed of the request fields without the signature and 
certificate, and the other is the signature (of the hash of the first part) and the certificate. 
The CSP may choose to validate the request by computing the request's hash and verifying that it matches the 
one signed by the Authorized Organization. The CSP may choose to validate the certificate as well. The 
generation of certificates and the nature of the assigning authority are out of scope of the present document. 
The CSP may choose just to keep the requests with their associated signatures and certificates for audit trail 
and any other validation or official procedure. 

• Digital signatures on RDHI messages for HI-A, by the CSP: 

The CSP signs the HI-A responses in exactly the same manner as the Authorized Organization signs the 
requests, i.e. signing the hash of the entire set of fields (including the time stamp) and sending the signed hash 
and its certificate (validating its public key) with the set of fields. Such digital signatures may serve the 
Authorized Organization injudicial procedures to show that responses coming from the CSP are certified by 
the CSP. This is especially recommended in case the CSP works in such a manner where each request 
(although electronically sent) is approved by a person. 

• Hashing and digital signatures on HI-B: 

For the purpose of the Authorized Organization providing court evidence that the retained data is truly CSP 
originated, the HI-B information is hashed, and these hashes are digitally signed. The HI-B information sent 
with the hashes and the CSP certificate (validating its public key). The Authorized Organization should keep 
the digitally signed hashes and certificates together with the data. 

For a technical description of these security measures see clause 8.4. 

8.4 Technical Security IVIeasures 

8.4.1 General 

NOTE: Connection level security measures are not independent of application level security measures. The 

XML/HTTP ecosystem has certain techniques, measures, and toolkits (for example for digital signatures) 
that have been proven to work together well. 

8.4.2 Connection Level 

The level and implementation of for example the TLS, IPSec and HTTPS security mechanisms are a matter of national 
regulations. 

8.4.3 Application Level 

8.4.3.1 Hashes 

This is an area for national implementations. 

8.4.3.2 Digital Signatures 

All digital signatures in the present document are DSS/DSA signatures according to FIPS PUB 186-2 [13]. 
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8.4.3.3 Hl-B Non-Repudiation 



In order to allow the authorities to verify the authenticity of the received data, hashes over the HI-B data may be sent. 
This verification may be used when the collected data is planned for evidential purposes. 

SHA-1 hash are computed and signed by DSS/DSA Signature. The digitally signed hashes are created for: 

• the entire HI-B data when sent in one bulk/message/transaction as a consequence of one HI-A request; or 

• a part of HI-B data when sent in one bulk/message/transaction as a consequence of one HI-A request. 

The digitally signed hash is always sent with its data, and not in subsequent transfers, for simplicity. This way there is 
an association of one digitally signed hash to one data transfer, and no hash coverage lapses occur. It is assumed that 
one HI-B bulk/message/transaction pertains to only one HI-A request. 

In the case of multi-part HI-B transmissions, the RecordNumber (which starts from zero for each HI-B set of responses) 
will be used in a sequential consecutive manner to number the records sent. Each subsequent HI-B transmission will 
start with the next sequential RecordNumber. This is to ensure that the Authorized Organization is able to make sure 
that the entire information has been received. The "Res" response (as opposed to the "Resinc") will indicate the last 
HI-B transmission for a specific request. The "Res" response will include RecordNumber as well conforming to this 
scheme. 

8.4.3.4 Digital Signatures and Message Structure 

The RetainedDataMessage defined in clause A. 3. 2.1 contains the RetainedDataDigest. Although the use of digest is 
optional (yet recommended), the RetainedDataMessage shall always be used for all messages. When the digest is not 
used, the retainedDataDigest will not be populated. 

When the digest is used, the RetainedDataHeader and RetainedDataPayload will be each separately BER encoded. The 
BER encoded fields will be used to populate their appropriate place in the message. A hash will be computed over the 
combined BER encoded fields (RetainedDataHeader and RetainedDataPayload, in this order). The hash will be digitally 
signed and be used to populate the retainedDataDigest field. 

For this purpose, two separate ASN.l definition modules have been provided in annex A. 
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Annex A (normative): 
Data fields 

A.1 Summary 

A. 1.1 Introduction to data fields 

Regardless of what data exchange technique is adopted for the request and delivery of retained data, a common data 
dictionary is necessary. This list of parameters must be consistent, extensible and maintainable. 

The CSP and Authorized Organization shall use the present document data dictionary. 

The present document does not supersede the EU Data Retention Directive [1] or national legislation. 

The present document defines the format of data to be transferred across the RDHI. In annexes B-E, a number of data 
elements are identified; they fall into three areas: 

• Those elements that are required to meet technical delivery requirements are marked MANDATORY (M). 

• Some elements are explicitly required to be retained by the EU Data Retention Directive [1], but their 
availability depends on network and other technical properties (e.g. if held by a third party). These are marked 
as CONDITIONAL (C). 

• It is for national agreement to determine the situations in which the elements marked OPTIONAL (O) are 
stored or delivered. The present document does not address the circumstances in which it is required to deliver 
such elements. The present document states that if such an element is present on the handover interface, then it 
shall be delivered in the format specified in annex A. 

The tables in clauses B.2, C.2, etc., assign each element M, C or O according to these definitions. Some of the 
lowest-level parameters are not listed in the tables in clauses B.2, C.2, etc.: they are defined only in the ASN.I in 
clauses B.3, C.3, etc. Such elements have the same status (M, C or O) as their parent. 

NOTE 1 : It is up to national legislation to decide whether and under what conditions the elements marked as 

Optional are required. Also, national legislation may decide for each Conditional field its status when the 
condition is not met. 

NOTE 2: In the formal ASN.I listing, the word OPTIONAL is used as defined in the ASN.I language, and is 
therefore not directly linked to the definition above. 

A.I .2 Choice of data modelling language 

The structure of the data is defined in ASN.I. An XML schema (derived from the ASN.I) is also given and is attached 
to the present document. If data exchange takes place using XML, then the XML schema shall be used. 

A. 1.3 Overview 

The data structure is broken down in the following way: 

• Message headers e.g. identifying information that is present on all messages (definitions in clause 6 and 
ASN.I in clause A.3.2). 

• Common fields i.e. parameters that might be used in more than one type of service (definitions in clause A.2 
and ASN.I in clause A.3.3). 

• Service-specific fields i.e. parameters that are only used in relation to one particular service (There is one 
annex for each service. Parameter definitions are in clauses B.2, C.2, etc. and ASN.I in clauses B.3, C.3, etc.). 
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A.2 Parameter definition for common fields 

A.2.1 RetainedDataHeader 
A.2. 1.1 Parameters 

The RetainedDataHeader structure is populated as per clauses 5 and 6. The parameters are as follows. 

Table A.I : RetainedDataHeader parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


requestID 


See clause 6.1.2. 


M 


cSPID 


See clause 6.1.3. 


M 


timeStamp 


See clause 6.1.4. 


M 


thirdPartyCSPID 


See clause 6.1.3.2. 






A.2. 1.2 RequestID parameters 

The RequestID structure uniquely identifies a request. See clause 6.1.2. 

Table A.2: RequestID parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


countryCode 


See clause 6.1.2. 


M 


author isedOrgani sat ionID 


See clause 6.1.2. 


M 


requestNumber 


See clause 6.1.2. 






A.2.2 RetainedDataPayload 
A.2. 2.1 RequestMessage parameters 

The use of the RequestMessage structure is described in clauses 5 and 6.3.2. The parameters are as follows. 

Table A.3: RequestMessage parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


request Priority 


See clause 6.3.3.1. 





request Parameters 


See clause 6.3.2. 





deliveryPointHIB 


See clause 5.5. 





maxHits 


See clause 6.3.3.2. 





nationalRequest Parameters 


Defined on a national basis. 






A.2. 2. 2 RequestAcknowlecJgement parameters 

The use of the RequestAcknowledgement structure is described in clause 5. The parameters are as follows. 

Table A.4: RequestAcknowledgement parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


suggest edCompletionTime 


Indicative time for expected completion of query. 
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A.2.2.3 ResponseMessage parameters 



The use of the ResponseMessage structure is described in clauses 5 and 6.2. The parameters are as follows. 

Table A.5: ResponseMessage parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


responseStatus 


See clause 6.2.2.2. 


M 


responsePayload 


Required if responseStatus is responseComplete or 
responselncomplete (see table A.6). 





nationalResponsePayload 


Defined on a national basis. 





responseNumber 


Number to identify partial results within parallel multi-part 
delivery. 





Table A.6: ResponseRecord parameters 


Field name 


Value 


M/C/0 
(see clause A.I. 1) 


recordNumber 


See clause 6.2.2.1. 


M 


recordPayload 


See clause 6.2. 


M 


additional Information 


See clauses 6.2.2.2 and 6.2.4. 





nationalRecordPayload 


Defined on a national basis. 






A.2.2.4 GetStatusMessage parameters 

The use of the GetStatusMessage structure is described in clause 5. The parameters are as follows. 

Table A.7: GetStatusMessage parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


requestNumbers 


See clause 5.3.1. 






A.2.2.5 StatusMessage parameters 

The use of the StatusMessage structure is described in clause 5. The parameters are as follows. 

Table A.8: StatusMessage parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


statusResponse 


See clause 5.3.1. 






Table A.9: StatusResponse parameters 



Field name 


Value 


M/C/0 
(see clause A.1.1) 


requestNumber 


See clause 5.3.1. 





request Status 


See clause 5.3.1. 
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A.2.2.6 ErrorMessage parameters 



The use of the ErrorMessage structure is described in clauses 5 and 6.4. The parameters are as follows. 

Table A.10: ErrorMessage parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


additional Information 


See clause 6.4. 






A.2.3 GenericSubscriberlnfo 
A.2.3.1 Parameters 

The GenericSubscriberlnfo structure encapsulates common subscriber information in a generic way. This structure is 
used in multiple service-specific annexes. 

If the subscriber is an organization or business, then information can be stored in Organizationlnfo. If the subscriber is 
an individual, then information can be stored in Individuallnfo. It is a matter for national implementations to decide 
which structure is appropriate for each service and subscriber. 

A.2.3. 2 Organizationlnfo parameters 

The Organzationlnfo field contains the following parameters. 

Table A.11 : Organizationlnfo parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


name 


Name of the organization. 


C 


contactDetails 


Address and contact details for point of contact. 


C 


nationalRegistrationID 


Provides a unique reference for this organization (e.g. a 
tax registration number). The format of this field is for 
national agreement. 






A.2.3. 3 ln(Jivi(Juallnfo parameters 

The Individuallnfo field contains the following parameters. 



Table A.12: Individuallnfo parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


name 


Name of the individual. 


C 


contactAddress 


Address and contact details for individual. 


C 


dateOfBirth 


Date of birth. 





gender 


Gender. 





identif icationNumber 


Provides a nationally-unique reference number. The 
format of this field is for national agreement. 





authenticationinf o 


Records how the individual authenticated themselves with 
the service provider (e.g. passport, utility bill, etc.). The 
format of this field is for national agreement. 





profession 


Profession of the individual. 
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A.2.4 PaymentDetails 



The PaymentDetails structure encapsulates common payment information in multiple service-specific annexes for 
subscriber data. The parameters are as follows. 

Table A.13: PaymentDetails parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


billingMethod 


Method of billing (e.g. debit, transfer, prepaid, etc.). 





bankAccount 


Sequence of specific data identifying the subscriber 
account within his bank. 





billingAddress 


Contact details of the billing address. 






A.3 ASN.1 definitions 



A.3.1 General 

A.3. 1.1 ASN.1 syntax tree 

Figure A. 1 shows the object identifier tree from the point of view of retained data handling. 



itu-t(O) 



ldentlfied-organlzation(4) 



etsi(O) 



securityDomaln(2) 



lawfullntercept(2) 



ITS 101 67 1 , 



retained Data(3) 



rdHeader(O) 



[TS 102 657] 



Figure A.I : Object identifier tree 

A.3.1 .2 General remarks on ASN.1 

Clause A. 3. 2 contains the top levels of the ASN.1 module. The ASN.1 details for each service are listed in annex B 
onwards. 

It is recommended to copy IRI parameters from LI standards wherever appropriate. Where a parameter is copied, it is 
essential that it has the same meaning and same format in both LI and RD standards. It is not recommended to IMPORT 
parameters from LI standards. 

The ASN.1 definitions are contained in a .txt file ("RDMessage, verl0.txt" contained in archive 
ts_102657v011001p0.zip) which accompanies the present document. 
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The XSD definitions are contained in a .xsd file ("RDMessage,verl0.xsd" contained in archive 
ts_102657v011001p0.zip) which accompanies the present document. 

A.3.2 ASN.1 Definitions for message headers 
A.3.2.1 IVIessage wrappers 

RDMessage {itu-t{0) identif ied-organization (4) etsi{0) securityDomain (2) retainedData (3) rdHeader{0) 
versionlO (10) } 

DEFINITIONS IMPLICIT TAGS ::= 

BEGIN 



Object Identifier definitions 



-- RetainedData Domainid 

retainedDataDomainId OBJECT IDENTIFIER ::= {itu-t{0) identif ied-organization {4 ) etsi{0) 

securityDomain (2) retainedData (3) } 



- - rdHeader 

rdHeaderld OBJECT IDENTIFIER ::= {retainedDataDomainId rdHeader{0) versionlO (10) 



Top level definitions for RDHI wrapper 



RetainedDataMessage : : = 

{ 

rdHeaderld 


SEQUENCE 




[0] OBJECT IDENTIFIER, 




retainedDataHeader 


[1] RetainedDataHeader, 




retainedDataPayload 


[2] RetainedDataPayload, 




retalnedDataDlgest 


[3] OCTET STRING OPTIONAL, 




-- The digitally 


signed hash of the combined fields above 


{retainedDataHeader and 


-- retainedDataPayload) 
} 





A.3.2. 2 IVIessage headers 

-- Definitions for Retained Data header information, present in every message 



RetainedDataHeader 

{ 

requestID 


:= SEQUENCE 


[1] RequestID, 


cSPID 


[2] CSPID, 


timeStamp 


[3] GeneralizedTime, 


thirdPartyCSPID 

} 


[4] CSPID OPTIONAL, 



CSPID ::= UTFSString 

-- Unique identifier for the CSP that issued the request 



RequestID ::= SEQUENCE 

{ 

countryCode 




[1] CountryCode, 


author isedOrgani sat ionID 


[2] AuthorisedOrganisationID, 


requestNumber 


[3] RequestNumber OPTIONAL, 


-- all messages except 


GetStatusMessage and StatusMessage have a request number 


-- {see clause 6.1.2) 
} 





CountryCode ::= UTFSString {SIZE{2)) 
-- A country code as per ISO 3166-1 [4] 
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AuthorisedOrganisationID: := UTFSString 

-- A unique identifier for an Authorized Organization issuing a Retained Data request 



RequestNumber ::= UTFSString 

-- Unique within a given country and Authorized Organization 



Definitions for Retained Data payload information 



RetainedDataPayload ::= CHOICE 






-- Payload can be a request 

{ 

r eque s tMe s s age 


response, error or acknowledgement 


[1] 


RequestMessage , 


r eque s t Acknowl edgemen t 


[2] 


RequestAcknowledgement , 


responseMessage 


[3] 


ResponseMessage , 


re spons eAcknowl edgemen t 


[4] 


ResponseAcknowledgement , 


errorMessage 


[5] 


Further Information, 


cancelMessage 


[6] 


CancelMessage , 


cancelAcknowledgement 


[7] 


CancelAcknowledgement , 


getstatusMessage 


[8] 


GetstatusMessage , 


statusMessage 


[9] 


StatusMessage , 


getResultsMessage 


[10] 


GetResultsMessage , 


supplementary-Request 


[11] 


SupplementaryRequest , 


supplementaryResponse 
} 


[12] 


SupplementaryResponse 



Definitions of Request message and acknowledgement 



RequestMessage ::= SEQUENCE 

{ 

requestPriority [1] RequestPriority OPTIONAL, 

requestParameters [2] RequestConstraints OPTIONAL, 

-- Optional only in case a warrant is transmitted independently of a request 
deliveryPointHIB [3] DeliveryPointHIB OPTIONAL, 

-- pre-arranged set of delivery address (es) of that specific Authorized Organization 
maxHits [4] INTEGER OPTIONAL, 

-- Maximum number of records to be returned. 

-- On a national basis maximum numbers could be considered 

-- In case of maxHit a responseFailed message is sent and no data is sent 

-- {see clause 6.3.3.2) 
natlonalRequestParameters [5] NationalRequestParameters OPTIONAL, 

-- To be defined on a national basis 

-- Only to be used in case the present document cannot fulfil the national requirements 

-- or to transmit a warrant. 



DeliveryPointHIB ::= UTFSString 



RequestConstraints ::= SEQUENCE 
r 






1 

equals 


[1] 


RetainedDataRecord 


OPTIONAL, 


notEqualTo 


[2] 


RetainedDataRecord 


OPTIONAL, 


lessThan 


[3] 


RetainedDataRecord 


OPTIONAL, 


-- For numerical 


values 






lessThanOrEqualTo 


[4] 


RetainedDataRecord 


OPTIONAL, 


-- For numerical 


values 






greaterThan 


[5] 


RetainedDataRecord 


OPTIONAL, 


-- For numerical 


values 






greaterThanOrEqualTo 


[6] 


RetainedDataRecord 


OPTIONAL, 


-- For numerical 


values 






startsWith 


[7] 


RetainedDataRecord 


OPTIONAL, 


-- For strings 








endsWith 


[S] 


RetainedDataRecord 


OPTIONAL, 


-- For strings 








isAMemberOf 

} 


[9] 


SEQUENCE OF RetainedDataRecord OPTIONAL, 



RequestPriority ::= OCTET STRING 

-- Priority considerations are a matter for national implementation 

-- This standard makes no statement regarding how such priorities are represented or used 
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Regue s t Acknowl edgemen t 

{ 



SEQUENCE 



suggestedCompletionTime [1] GeneralizedTime OPTIONAL, 
-- Indicative time that results will be ready 
-- Purely informational, not binding for either party 



Definitions of Response message and acknowledgement 



ResponseMessage 



SEQUENCE 



responseStatus [1] ResponseStatus, 

responsePayload [2] SEQUENCE OF ResponseRecord OPTIONAL, 

-- Clause 6 explains use of this field 

-- A responseUnavailable message shall not have a responsePayload {see clause 5.3.1) 
-- The responseComplete and responselncomplete message shall have a responsePayload 
-- If there are no responses, the responsePayload is present but has zero entries 

natlonalResponsePayload [3] NationalResponsePayload OPTIONAL, 
-- to be defined on a national basis 
-- only to be used in case the present document cannot fulfil the national requirements 

responseNimber [4] INTEGER OPTIONAL 

-- number to identify partial results within parallel multi-part delivery 



Re 

{ 


sponseStatus ::= CHOICE 














responseComplete 


[1] 


NULL, 












--No further result 


s to come 












responselncomplete 


[2] 


NULL, 












-- There will be at 


least one 


further 


response 


message 


to come 




responseUnavailable 


[3] 


NULL, 












-- See clause 5.3.1 
















responseFailed 


[4] 


Further Information, 






} 


-- See clauses 6.2.2 


.2 


and 6 . 3 


.3.2 









ResponseRecord : : = SEQUENCE 

{ 

recordNiimber 






[1] 


INTEGER, 


recordPayload 


[2] 


RetainedDataRecord, 


additional Information 


[3] 


Additionallnformation OPTIONAL, 


-- see clause 6.2.4 






nationalRecordPayload 


[4] 


NationalRecordPayload OPTIONAL, 


-- To be defined on a 


national basis 


-- Only to be used in 
} 


case 


the present document cannot fulfil the national requirements 



Additionallnformation 



SEQUENCE 



contactlnformation [1] UTFSString OPTIONAL, 

-- Name or address of operator or person who may have further information 
otherlnformation [2] UTFSString OPTIONAL, 



RetainedDataRecord 

r 




CHOICE 






1 


telephonyRecord 


[1] 


TelephonyRecord, 








-- Details are 


def 


ined 


in Annex B 








messageRecord 




[2] 


MessageRecord, 








-- Details are 


def 


ined 


in Annex C 








networkAccess 




[3] 


NetworkAccessRecorc 


, 






-- Details are 


def 


ined 


in Annex E 








multimediaRecord 


[4] 


MultimediaRecord 








-- Details are 


def 


ined 


in Annex D 






} 


-- Other services will be included {as 


they are 


implemented) 
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ResponseAcknowledgement ::= CHOICE 

{ 

-- Acknowledges a response has been 




sent 


acknowledgeCompleteResults [1] 


NULL, 


acknowledgePartialResults [2] 


NULL, 


acknowledgePartialResultsNiunber [3] 


INTEGER 


-- number to acknowledge a specific 
} 


resultMessage within parallel multi-part delivery 



-- Definitions of an error message and acknowledgment 



Further Information 



SEQUENCE 



information [1] UTFSString, 

contactlnformation [2] UTFSString OPTIONAL, 



-- Definitions of a cancel message and acknowledgement 



CancelMessage : := NULL 

-- Cancels an active request 



CancelAcknowledgement : = NULL 

-- Acknowledges the receipt of a cancel message {no other information required) 



Definitions of status request and response messages 



GetStatusMessage ::= SEQUENCE 


requestNumbers [1] 


SEQUENCE OF RequestNumber , 


StatusMessage ::= SEQUENCE 




statusResponse [1] 


SEQUENCE OF StatusResponse, 


StatusResponse : : = SEQUENCE 




requestNiimber [1] 


RequestNumber, 


requestStatus [2] 


RequestStatus , 


RequestStatus ::= CHOICE 




ready 


[1] NULL, 


incompleteResultsReady 


[2] NULL, 


failureResponseReady 


[3] NULL, 


notReady 


[4] NULL, 


error 


[5] Furtherlnformation, 


inOelivery 


[S] NULL, 


invalidRequestID 

} 


[7] NULL, 
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-- Definitions of status get results messages 



GetResultsMessage ::= NULL 

-- No further information required {the RequestID is given in the header) 



National parameters 



NationalRequestParameters ::= SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE {2)), 

-- Country Code according to ISO 3166-1 [4] , 

-- the country to which the parameters inserted after the extension marker apply. 

-- In case a given country wants to use additional national parameters according to its law, 
-- these national parameters should be defined using the ASN.l syntax and added after the 
-- extension marker {...). 

-- It is recommended that an version indicator is included in the national parameters 
-- definition. 
J 

NationalResponsePayload : : = SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE {2)), 

-- see comment in NationalRequestParameters 



NationalRecordPayload : : = SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE {2)), 

-- see comment in NationalRequestParameters 



SupplementaryRequest ::= CHOICE 

{ 

nationalSupplementaryRequest [1] NationalSupplementaryRequest, 



SupplementaryResponse ::= CHOICE 

{ 

nationalSupplementaryResponse [1] NationalSupplementaryResponse , 



NationalSupplementaryRequest ::= SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE {2)), 

-- Country Code according to ISO 3166-1 [4] , 

-- the country to which the parameters inserted after the extension marker apply. 

-- In case a given country wants to use additional national parameters according to its law, 
-- these national parameters should be defined using the ASN.l syntax and added after the 
-- extension marker {...). 

-- It is recommended that a version indicator is included. 
J 

NationalSupplementaryResponse : : = SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE {2)), 

-- Country Code according to ISO 3166-1 [4] , 

-- the country to which the parameters inserted after the extension marker apply. 

-- In case a given country wants to use additional national parameters according to its law, 

-- these national parameters should be defined using the ASN.l syntax and added after the 

-- extension marker {...). 

-- It is recommended that a version indicator is included. 
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A.3.3 ASN.1 definitions for common fields 



TimeSpan : : = SEQUENCE 




1 

startTime 


[1] 


GeneralizedTime OPTIONAL, 


endTime 


[2] 


GeneralizedTime OPTIONAL, 


durationTime 


[3] 


INTEGER OPTIONAL 


-- duration 
} 


in 


seconds 



Definitions for Generic Subscriber Information 



GenericSubscriberlnfo 

{ 

organlzatlonlnfo 
individual Info 



= SEQUENCE 

[1] Organizationlnfo OPTIONAL, 
[2] Individuallnfo OPTIONAL, 



Organizationlnfo 

{ 



SEQUENCE 



name [1] UTFSString OPTIONAL, 

-- name of the organization 
contactDetails [2] ContactDetails OPTIONAL, 

-- address, and name/phone number of a point of contact 
nationalRegistrationID [3] UTFSString OPTIONAL, 

-- e.g. social security number 



Individuallnfo ::= 

{ 

name 


SEQUENCE 








[1] 


PersonName OPTIONAL, 


contactAddress 




[2] 


ContactDetails OPTIONAL, 


dateOfBirth 




[3] 


GeneralizedTime OPTIONAL, 


gender 

{ 

male (0) , 




[4] 


ENUMERATED 








female (1) , 








} OPTIONAL, 








identif icationNumber 


[5] 


UTFSString OPTIONAL, 


authenticationlnfo 


[6] 


Authenticationlnfo OPTIONAL, 


profession 

} 




[7] 


UTFSString OPTIONAL 



PersonName : : = SEQUENCE 














1 


salutation 


[1] 


UTFSString 


OPTIONAL, 










surname 


[2] 


UTFSString 


OPTIONAL, 










-- the non-chosen or inherited name of an individual, e 


.g. 


"Arend" 




surnamePref ix 


[3] 


UTFSString 


OPTIONAL, 










-- any prefix before 


the surname, e.g. "von" 


"van der" 








surnameSuf f ix 


[4] 


UTFSString 


OPTIONAL, 










-- any suffix after 


the 


surname , e 


g. "Jr", 


'III" 








middleNames 


[5] 


UTFSString 


OPTIONAL, 










-- that part of the 


name excluding 


forename. 


separable 


and 


preceding the surname 




f irstname 


[6] 


UTFSString 


OPTIONAL, 










-- the first name or initials, e.g 


"Peter" 










secondsurname 


[7] 


UTFSString 


OPTIONAL, 










-- a second surname 


is 


jsed in several countries 








secondsurnamePref ix 


[S] 


UTFSString 


OPTIONAL, 








} 


secondsurnameSuf f ix 


[9] 


UTFSString 


OPTIONAL 









ContactDetails ::= 

{ 

address 


SEQUENCE 








[1] 


Addresslnformation OPTIONAL, 


emailAddress 




[2] 


UTFSString OPTIONAL, 


contactNumber 




[3] 


SEQUENCE OF PartyNumber OPTIONAL, 
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-- several numbers {work, home, mobile) may be given for a single 


subscriber 




additionalEmailAddresses [4] SEQUENCE OF UTFSString OPTIONAL 




} 


-- several email addresses may be given for a single subscriber 





Address Information 

{ 

f latNiunber 


: : = SEQUENCE 


[1] UTFSString OPTIONAL, 


bui IdingName 


[2] UTFSString OPTIONAL, 


buildingNiunber 


[3] UTFSString OPTIONAL, 


streetName 


[4] UTFSString OPTIONAL, 


poBox 


[5] UTFSString OPTIONAL, 


-- PO box or Response number 


postalCode 


[6] UTFSString OPTIONAL, 


-- Postal code. Example: 2289AC 


region 


[7] UTFSString OPTIONAL, 


province 


[S] UTFSString OPTIONAL, 


language 


[9] UTFSString OPTIONAL, 


city 


[10] UTFSString OPTIONAL, 


country 


[11] CountryCode OPTIONAL, 


-- Country 


code as defined in ISO 3166-1 [4] 


validity 


[12] TimeSpan OPTIONAL, 


-- time from which the address was registered 
} 



Authenticationlnfo 



SEQUENCE 



authenticationType [1] UTFSString OPTIONAL, 

-- the type of document used to authenticate, 
authenticationNumber [2] UTFSString OPTIONAL, 



e.g. passport, driver's license 



the number of the document used to authenticate 



PaymentDe tails 

{ 



SEQUENCE 



bill ingMe thod 
bankAccount 
bill ingAddr e s s 



[1] BillingMethod OPTIONAL, 
[2] BanlcAccount OPTIONAL, 
[3] ContactDetails OPTIONAL, 



BankAccount 



SEQUENCE 



iBAN 

bIC 

accountHolder 

nationalAccountNumber 



[1] IBAN OPTIONAL, 

[2] BIC OPTIONAL, 

[3] UTFSString OPTIONAL, 

[4] UTFSString OPTIONAL, 



-- To be used in case that the account holding banlc has no IBAN 
nationalBankNumber [5] UTFSString OPTIONAL, 

-- To be used in case that the account holding banlc has neither IBAN nor BIC 
bankName [6] UTFSString OPTIONAL, 



IBAN 


:= UTFSString 


-- 


International BanJcing Account Number 


-- 


format as per ISO 13616-1:2007 [2S] 



BIC 


:= UTFSString 
-- Business Identifier Code 






-- format as per ISO 9362:2009 


[29] 



BillingMethod ::= ENUMERATED 

{ 

debit (0) , 
transfer (1) , 
prepaid (2) , 
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A.3.4 Schematic representation of top level ASN.1 



RetalnedDataMessage 

- rdHeaderlD 

- retalnedDataHeader 

requestID 

- countryCode 

- authorisedOrganisationID 
^ requestNumber 

CSPID 

time St amp 

thirdPartyCSPID 

- retainedDataPayload 
requestMessage 

request Priority 
request Parameters 

- equals 
^ RetainedDataRecord 

- notEquals 
^ RetainedDataRecord 

lessThan 

^ RetainedDataRecord 
lessThanOrEqualTo 

^ RetainedDataRecord 
greaterThan 

^ RetainedDataRecord 

- greaterThanOrEqualTo 
^ RetainedDataRecord 

startsWith 

^ RetainedDataRecord 
endsWith 

^ RetainedDataRecord 
isaMemberOf 

^ Sequence of RetainedDataRecord 

- deliveryPointHIB 

- maxHits 
^ nationalRequestParameters 

request Acknowledgement 

responseMessage 

responseAcknowledgement 

errorMessage 

cancelMessage 

cancelAcknowledgement 

- getStatusMessage 

- statusMessage 
getResultsMessage 
supplement aryMes sage 

^ supplementaryResponse 
retalnedDataDlgest 



See figure A. 3 
See figure A. 3 
See figure A. 3 
See figure A. 3 
See figure A. 3 
See figure A. 3 
See figure A. 3 
See figure A. 3 

See figure A. 3 



NOTE: This figure should be regarded only as an aid to understanding. In the event of a discrepancy between this 
figure and the text of the ASN.1 specification the ASN.1 specification is the leading one. 

Figure A.2: Schematic representations of the major top-level ASN.1 structures 



RetainedDataRecord 

telephonyRecord - see Annex B 
messageRecord - see Annex C 
multlmediaRecord - see Annex D 

^ networkAccess - see Annex E 



NOTE: This figure should be regarded only as an aid to understanding. In the event of a discrepancy between this 
figure and the text of the ASN.1 specification the ASN.1 specification is the leading one. 

Figure A.3: Schematic representations of the RetainedDataRecord structure 
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GenericSubscriberlnfo 

- organlzatlonlnfo 

name 

contactDetails 
^ nationalRegistration 
^ individual Info 

- name 

- contactAddress 

- dateOfBirth 
gender 

identif icationNumber 
authenticationlnfo 

^ profession 

NOTE: This figure should be regarded only as an aid to understanding. In the event of a discrepancy between this 
figure and the text of the ASN.1 specification the ASN.1 specification is the leading one. 

Figure A.4: Schematic representations of thie GenericSubscriberlnfo structure 

PaymentDe tails 

- billingMethod 

- bankAccount 

^ billingAddress 

NOTE: This figure should be regarded only as an aid to understanding. In the event of a discrepancy between this 
figure and the text of the ASN.1 specification the ASN.1 specification is the leading one. 

Figure A.5: Schematic representations of the PaymentDetails structure 
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Annex B (normative): 

Service-specific details for telephony services 



B.1 Scope 



Telephony services covers those services offering the facilities listed below. It covers services that provide PSTN/ISDN 
functionality (either offered over PSTN/ISDN or emulated PSTN/ISDN over IP) including GSM/UMTS-CS, SMS and 
MMS. 

A user may expect a service that offers the capability e.g. to: 

• Dial telephone numbers. 

• Get a dial tone and outgoing/incoming ringing tones. 

• Conduct conversation with one or more other parties. 

• Hang up. 

• Answer when the phone rings. 

• Use a basic set of value-added services. 



B.2 Telephony fields 
B.2.1 General 

This clause describes the fields and parameters of the Telephony ASN.l definitions given in clause B.3. This clause is 
to be read in conjunction with the notes in the ASN.l definitions themselves and the definitions in clause A. 1.1. 

B.2. 2 Telephony Subscriber 

This clause contains information on subscriber, and the subscribed services, independent of actual usage. 

Table B.I : TelephonySubscriber parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


subscriberlD 


A unique identifier for a particular subscriber within a CSP. 


C 


genericSubscriberInf o 


A unique identifier for this particular subscriber within the CSP. 





telephonySubscriberlnf o 


Service specific information about the subscriber. 





subscribedTelephonyServices 


List of services details that a subscriber (or account) may 
have. 






B. 2.2.1 subscriberlD 

subscriberlD is a unique identifier for a particular subscriber within a CSP, for example an account number. The format 
and content of this field is for CSPs to determine. The only requirement is that the subscriber ID is unique for each 
subscriber within the CSP. 
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B.2.2.2 genericSubscriberlnfo 

Common information such as name and address is stored in the GenericSubscriberlnfo structure. This is defined in the 
service-independent annex A. 

B.2.2.3 telephonySubscriberlnfo 

Information about the subscriber which is specific to telephony services is contained in the TelephonySubscriberlnfo 
structure. This is for further study. 



B.2.2.4 subscribecJTelephonyServices 



B.2.2.4.1 



Description 



There shall be a SubscribedTelephonyService structure for each subscription the subscriber holds. The parameters are 
as follows. 

Table B.2: SubscribedlelephonyServices parameters 



Field name 


Value 


M/C/0 

(see clause 

A.1.1) 


servicelD 


A unique identifier within the operator for the service or 
tariff subscribed to. 





providerlD 


A unique identifier for the service provider. The format 
of this field is to be determined by national agreement. 





timeSpan 


Time over which the subscription was held. If the 
subscription is active, the endTime shall not be 
populated. 





regis teredNumbers 


The telephone number(s) assigned to the subscriber as 
part of this subscription, if applicable (multiple e.g. in 
GSM for voice/fax/data, ISDN MSNs). 





serviceType 


The type of service subscribed to. 





installationAddress 


The installation address for the subscriber's equipment, 
if applicable. 





connect ionDate 


Date when the subscriber was actually connected that 
may differ from the start of subscription. 





iMSI 


IIVISI of the subscriber. 





carrierPreselect 


Indication of the carrier preselection. 





lineStatus 


CSP specific description of the current line status. 





allocatedDevicelDs 


List of all known devices allocated to this user for this 
subscription. The user may use other devices in 
addition (or instead of) these devices. 





pUKCode 


PUK code for the SIIVI card associated with this 
subscription, if applicable. 





pUK2Code 


PUK2 code for the SIM card associated with this 
subscription, if applicable. 





iMEI 


IMEI of the subscriber. 





nationalTelephonySubscriptionInf o 


Defined on a national basis. 





paymentDetails 


Details for payment (e.g. associated bank account, 
billing method or billing address). 






B.2.3 Telephony Billing Details 



The TelephonyBillingDetails structure gives information about the subscribers billing history for a particular 
subscription. The parameters are as follows. 
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Table B.3: TelephonyBMIingDetails parameters 



Field name 


Value 


M/C/0 
(see clause A.1.1) 


subscriberlD 


A unique identifier for a particular subscriber within a CSP. 





servicelD 


A unique identifier within the operator for the service or tariff 
subscribed to. 





billingAddress 


The billing address for this subscription. 





billingldentif ier 


A unique identifier for billing purposes. The format of this field is for 
CSPs to determine. 





billingRecords 


A sequence of billing records, one for each payment by the subscriber 
on this subscription - see clause B.2.3.1 . 






B.2.3.1 BillingRecords 

Each billing record contains information for a particular payment. The parameters are as follows. 

Table B.4: BillingRecords parameters 



Field name 


Value 


M/C/0 

(see clause 

A.1.1) 


time 


Time of the payment. 





place 


Location of the payment. 





amount 


The amount of the payment, in currency specified. 





currency 


Currency of payment, in ISO 4217 [5] format. 





method 


Type of payment (e.g. credit card, top-up voucher). The 
format of this field is for agreement with the CSP. 





nationalTelephonyBillingRecords 


Defined on a national bases. 





transactionID 


Unique reference. 





transact ionStatus 


Status of the transaction (i.e. "declined", "succeeded" 
etc.). 






B.2.4 Telephony ServiceUsage 
B.2.4.1 Parameters 

The TelephonyServiceUsage structure is used for service usage information, such as call data records. The parameters 
are as follows. 

Table B.5: TelephonyServiceUsage parameters 



Field name 


Value 


M/C/0 
(see clause A.1.1) 


partyinf ormation 


A list of partylnformation structures (see clause B. 2.4.2). 


C 


communicationTime 


Total time for this service usage. Not that the time of 
involvement of individual parties may be shorter (see 
clause B.2.4.2). 


C 


event Information 


A list of telephony events that occurred during this call. 
Telephony events may relate to Call Forwarding, 
Conference Calls, Messaging, etc. (listed in the ASN.1 in 
clause B.3). 





endReason 


The Q.850 cause code for the termination of the call. 





communicationType 


The type of call. 


c 


bearerService 


The bearer service for the call. 


c 


sms Information 


SIVIS information for the service usage, if applicable. 





ringDuration 


Ring duration, given in seconds. 





mms Information 


MMS information for service usage, if applicable. 





nationalTelephonyServiceUsage 


Defined on a national basis. 
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B. 2.4.2 Party Information 



A Partylnformation structure is filled in for each party involved in the communication. The parameters for Telephony 
services are as follows. 

Table B.6: Partylnformation parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


partyRole 


Role for this party (e.g. called, calling). 


C 


partyNumber 


Number for this party in E. 164 format. 


C 


subscriberlD 


Subscriber identifier, unique identifier for subscriber 
(see clause B.2.2.1). 





devicelD 


Device identifier. 


c 

(see note 1) 


locations 


Location(s) encountered during a call. 



(see note 2) 


communicationTime 


Time that this party was involved in the call, if this 
was a multiparty call. Shall be omitted if it is the same 
as the time of the whole service usage 
(see clause B. 2.4.1). 





iMSI 


IMSI of the party. 


C 


natureOf Address 


Nature of the address - may be "International 
number", "national number" or "subscriber number". 





f orwardedTransf erredNumber 


Forwarded number if call was transferred. 





terminatingTransf erredNumber 


Terminating number if call was transferred. 





emailAddress 


e mail address of the party for MMS. 





iMEI 


IIVIEI of the party. 





detailedLocation 


Detailed location information per call and party, e.g. 
geoCoordinates for this partyNumber. 





nationalTelephonyParty Information 


Defined on a national basis. 





partyType 


Type of party (e.g. operator provided voicemail, etc.). 





dialledDigits 


Digits dialled by the party (e.g. subscriber controlled 
input). 





NOTE 1 : Further information is given in EU DRD [1], clause 5.e.2. 

NOTE 2: For mobile calls, only the start location is explicitly mentioned in the EU DRD [1]. 



B.2.4.3 SMSInformation 

A SMsInformation structure if filled in when a SMS is involved in the communication. The parameters are as follows. 

Table B.7: Smslnformation parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


smsEvent 


Type of message event - may be single short message, a part of a 
composite message, a composite message, a notification message. 





smsType 


Type of sms transferred on SC - IVIS interface. 





smsStatus 


Status reached by the sms, i.e. submitted, delivered (listed in the ASN.1 in 
clause B.3). 





smsCmRefNr 


Concatenated short message reference number, in 3GPP TS 23.040 [16]. 





smsNumOfSM 


Number of short messages transferred in case of composite messages. 





smsNotifyInd 


Delivery notification message generated by messaging center. 





smsProtocolId 


Transfer Layer Protocol - Protocol Identifier (TP-PID), in 3GPP 
TS 23.040 [16]. 
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B.2.4.4 Mmslnformation 

A Mmslnformation structure is filled in when a MMS is involved in the communication. The parameters are as follows. 

Table B.8: Mmslnformation parameters 



Field name 


Value 


M/C/0 
(see clause A.1.1) 


mmsEvent 


Type of message event - may be a multimedia message, a multimedia 
notification message, a multimedia delivery report message, a multimedia 
read reply message. 





mmsStatus 


Status reached by the mms, i.e. submitted, delivered (listed in the ASN.1 
in clause B.3). 

The status "delivered-application" indicates that the IVIMS was retrieved by 
something other than a mobile handset; for example, a web browser. 





mmsNotif Ind 


Delivery notification message generated. 





mmsMsgMod 


IVIodifications performed on the message - may be none, modified, 
stripped (if some parts of the message has been removed). 






B.2.5 TelephonyDevice 
B. 2.5.1 General 

The TelephonyDevice structure is used to describe devices such as mobile handsets. 

Table B.9: TelephonyDevice parameters 



Field name 


Value 


M/C/0 
(see clause A.1.1) 


devicelDType 


Indicates the type of identifier used in TelephonyDevicelD, e.g. \W\E\. 
(See ASN.1 for permissible types). 


C 


telephonyDevicelD 


Unique identifier for the telephony device. If this identifier happens to 
have a particular format (e.g. IMEI), then this may be indicated using 
devicelDType. 


C 


subscriberlD 


Identity of a known user of this equipment. 
This identity may be registered in cases where the provider has 
supplied the user with a device. It may also be recorded ad-hoc 
based on service usage data, depending on national legislation. 






B.2.6 TelephonyNetworkElement 
B.2.6.1 General 

The TelephonyNetworkElement structure is used to describe network elements such as mobile cells. 

Table B.10: TelephonyNetworkElement parameters 



Field name 


Value 


M/C/0 

(see clause 

A.1.1) 


telephonyNetworklD 


Unique identifier for the network element (e.g. IVISC ID). 





cell Information 


Location information for this network element. See 
location parameters below (clause B.2.6.2). 


C 


validity 


Time period during which the information given in this 
structure is or was valid. 





nationalTelephonyNetworkElement 


Defined on a national basis. 





transmitterDetails 


Characteristics of the transmitter, e.g. beam-width, 
radiated power, antenna height, frequency, technology. 
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B.2.6.2 Location parameters 



B.2.6.2.1 General 

The Location structure contains location information for the network element. 

Table B.11: Location parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


el64 -Number 


E.I 64 number in ISUP format (see EN 300 356 [7]). 





globalCelllD 


Global cell ID in TS 100 974 [8] format. 





rAI 


Routing Area Identifier in current SGSN, in 3GPP TS 24.008 [9] 
format, without Routing Area Identification lEI (only last 6 octets are 
used). 





gsmLocation 


GSM location, details as defined in clause B.3. 





umtsLocation 


UIVITS location, details as defined in clause B.3. 


c 


sAI 


Service Area Identifier, in 3GPP TS 25.413 [31] format. 





oldRAI 


Routing Area Identifier in old SGSN, in 3GPP TS 24.008 [9] format, 
without Routing Area Identification lEI (only last 6 octets are used). 





postalLocation 


Postal address of the location. 





extendedLocation 


Extended location information (see clause B.2.6.2. 4). 






B.2.6.2.2 GSM Location Information 



Table B.12: GSMLocation parameters 



Field name 


Value 


M/C/0 
(see clause A.1.1) 


geoCoordinates 


Geographical latitude-longitude location. Formats as described in 
ASN.1. 





utmCoordinates 


Universal Transverse IVIercator location. Formats of individual fields 
described in ASN.1 comments. 





utmRef Coordinates 


Universal Transverse Mercator reference co-ordinates. 





wGS 84 Coordinates 


WGS84 co-ordinates, format as defined in 3GPP TS 03.32 [12]. 





geoCoordinatesDec 


Geographical decimal latitude-longitude location. Formats as 
described in ASN.1. 






B.2.6.2.3 UMTS Location Information 

Table B.13: UMTSLocation parameters 



Field name 


Value 


M/C/0 
(see clause A.1.1) 


point 


Geographical latitude-longitude location. Latitudes and longitudes 
specified as integers, with additional latitude sign. 





pointWithUncertainty 


Geographical latitude-longitude location with additional uncertainty 
code to indicate radius of uncertainty. 





polygon 


Sequence of latitude-longitude locations that define a polygon. 
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B.2.6.2.4 Extended Location 

Table B.I 4: Extended location parameters 



Field name 


Value 


IVI/C/0 
(see clause A.I. 1) 


spot 


Geographical coordinate or postal address of the location, details as defined 
in clause B.3. 


C 


circle 


Geographical coordinate or postal address of the location, each with radius, 
details as defined in clause B.3. 





region 


Corner marks of an area, consisting of geographical coordinates or postal 
addresses of locations, details as defined in clause B.3. 





route 


Stretch of way, consisting of geographical coordinates or postal addresses 
of locations, details as defined in clause B.3. 






B.2.6.3 TransmitterDetails parameters 
B.2.6.3.1 General 

The TransmitterDetails structure contains transmitter information for the network element. 

Table B.15: TranmitterLocation parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


alternativelD 


Alternative naming scheme for cells. 





beamWidth 


Beam width in degrees. 





radiatedPower 


Radiated power in watts. 





antennaHeight 


Height of antenna from ground in metres. 





range 


Indication of range or radius of cell or sector coverage in 
meters. 





frequency 


Transmitter frequency in kHz. 





technology 


Transmitter technology, e.g. gen2G, gen3G. 





nationalTransmitterDetails 


Defined on a national basis. 






B.3 ASN.1 definitions for telephony 



TelephonyRecord ::= CHOICE 

{ 

telephonySubscriber 






[1] 


TelephonySubscriber, 


telephonyBillingDe tails 


[2] 


TelephonyBillingDetails , 


telephonyServiceUsage 


[3] 


TelephonyServiceUsage, 


telephonyDevice 


[4] 


TelephonyDevice, 


telephonyNetworkElement 

} 


[5] 


TelephonyNetworkElement , 



-- Definitions of Subscriber Data 
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Telephony-Subscriber : : = SEQUENCE 

{ 

subscriberlD [1] TelephonySubscriberld OPTIONAL, 

-- unique identifier for this subscriber, e.g. account number 
genericSubscriberlnfo [2] GenericSubscriberlnfo OPTIONAL, 

-- generic personal information about this subscriber 
telephonySubscriberlnfo [3] TelephonySubscriberlnf o OPTIONAL, 

-- service-specific information about this subscriber 
subscribedTelephonyServices [4] SEQUENCE OF SubscribedTelephonyServices OPTIONAL, 

-- a subscriber {or account) may have more than one service listed against them 

nationalTelephonySubscriberlnfo [5] NationalTelephonySubscriberlnfo OPTIONAL 
-- To be defined on a national basis 
-- Only to be used in case the present document cannot fulfil the national requirements 



Nat ionalTelephonySubscriber Info 

{ 



SEQUENCE 



countryCode [1] UTFSString {SIZE {2)), 

-- see comment in NationalRequestParameters 



TelephonySubscriberld ::= UTFSString 

-- unique identifier for this subscriber. 



e.g. account number 



TelephonySubscriberlnfo 

-- Reserved 



SubscribedTelephonyServices 

{ 



SEQUENCE 



servicelD [1] UTFSString OPTIONAL, 

-- Unique identifier for this service within the operator 
providerlD [2] UTFSString OPTIONAL, 

-- Unique identifier for the service provider 
timeSpan [3] TimeSpan OPTIONAL, 

-- Start and end data, if applicable, of the subscription 
regis teredNumbers [4] SEQUENCE OF PartyNumber OPTIONAL, 

-- The set of telephone numbers registered for this service 
registeredlCCID [5] UTFSString OPTIONAL, 

serviceType [6] TelephonyServiceType OPTIONAL, 

installationAddress [7] Addresslnformation OPTIONAL, 

-- installation address, if different from the registered address 
connectionDate [S] GeneralizedTime OPTIONAL, 

-- Date the subscriber was actually connected 

-- {May differ from the start of subscription) 
iMSI [9] IMSI OPTIONAL, 

carrierPreselect [10] BOOLEAN OPTIONAL, 

lineStatus [11] UTFSString OPTIONAL, 

-- CSP-specific description of current line status, e.g. "Active", "Ceased", etc. 



[12] SEQUENCE OF TelephonyDevicelD OPTIONAL, 

[13] UTFSString OPTIONAL, 

[14] UTFSString OPTIONAL, 

[15] SEQUENCE OF IMEI OPTIONAL, 

[16] NationalTelephonySubscriptionlnfo OPTIONAL, 
--To be defined on a national basis 

-- Only to be used in case the present document cannot fulfil the national requirements 

paymentDetails [17] PaymentDetails OPTIONAL 



allocatedDevicelDs 

pUKCode 

pUK2Code 

iMEI 

nationalTelephonySubscriptionlnfo 



NationalTelephonySubscriptionlnfo 

{ 



SEQUENCE 



countryCode [1] UTFSString {SIZE {2)), 

-- see comment in NationalRequestParameters 
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TelephonyBillingDetails : ; 

{ 

subscriber ID 
servicelD 
bill IngAddr e s s 
billingldentif ier 
billingRecords 



SEQUENCE 



[1] TelephonySubscriberld OPTIONAL, 

[2] UTFSString OPTIONAL, 

[3] ContactDetails OPTIONAL, 

[4] Billingldentifier OPTIONAL, 

[5] SEQUENCE OF BillingRecords OPTIONAL, 



nationalTelephonyBillingDetails [6] NationalTelephonyBillingDetails OPTIONAL 
-- To be defined on a national basis 
-- Only to be used in case the present document cannot fulfil the national requirements 



Nat ionalTelephonyBillingDe tails 



SEQUENCE 



countryCode [1] UTFSString {SIZE (2)), 

-- see comment in NationalRequestParameters 



} 



Billingldentifier ::= OCTET STRING 

-- Used to correlate billing information 

-- useful if the bill-payer is not the subscriber, e.g. company mobiles 



ingRecords : : = SEQUENCE 




time 


[1 


place 


[2 


amount 


[3 


currency 


[4 


-- as per ISO 4217 [5] 




method 


[5 


-- i.e. credit card etc. 





GeneralizedTime OPTIONAL, 

UTFSString OPTIONAL, 

REAL OPTIONAL, 

UTFSString {SIZE{3)) OPTIONAL, 

UTFSString OPTIONAL, 



nationalTelephonyBillingRecords [6] NationalTelephonyBillingRecords OPTIONAL, 

-- To be defined on a national basis 

-- Only to be used in case the present document cannot fulfil the national requirements 
transactionID [7] UTFSString OPTIONAL, 

-- Unique reference for this transaction/billing record 

-- Details to be defined on a national basis 
transactionStatus [S] UTFSString OPTIONAL 

-- Status of the transaction {i.e. "declined", "succeeded" etc.) 

-- Details to be defined on a national bases 



Nat ionalTelephonyBi 11 ingRecords 

{ 



SEQUENCE 



countryCode [1] UTFSString {SIZE {2)), 

-- see comment in NationalRequestParameters 



TelephonyServiceType : : = ENUMERATED 

{ 

private {0) , 
privatePABX{l) , 
publicPayphone {2) , 
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-- Definitions of Service Usage Data 



TelephonyServiceUsage 



SEQUENCE 



party-Information [1] SEQUENCE OF TelephonyPartylnformation OPTIONAL, 

-- This parameter provides the concerned party {Originating, Terminating or 
-- forwarded party), the identity (ies) of the party and all the information 
-- provided by the party 

communicationTime [2] TimeSpan OPTIONAL, 

-- Time and duration of the communication 



event Information 



[3] SEQUENCE OF TelephonyEventlnf ormation OPTIONAL, 



A list of events that occurred during this service usage 



endReason 

-- Q.850 
communicationType 
bearerService 
sms Information 
ringOuration 



[4] INTEGER OPTIONAL, 
cause code for call termination 

[5] TelephonyCommunicationType OPTIONAL, 
[6] TelephonyBearerService OPTIONAL, 
[7] Smslnformation OPTIONAL, 
[8] INTEGER OPTIONAL, 



mmslnformation [9] Mmslnformation OPTIONAL, 

nationalTelephonyServiceUsage [10] NationalTelephonyServiceUsage OPTIONAL 

-- To be defined on a national basis 

-- Only to be used in case the present document cannot fulfil the national requirements 



NationalTelephonyServiceUsage 

{ 



SEQUENCE 



countryCode [1] UTFSString {SIZE (2)), 

-- see comment in NationalRequestParameters 



TelephonyPartylnformation 

{ 

partyRole 
partyNiimber 
subscriber ID 
devicelD 
locations 



SEQUENCE 



[1] TelephonyPartyRole OPTIONAL, 

[2] PartyNumber OPTIONAL, 

[3] TelephonySubscriberld OPTIONAL, 

[4] TelephonyDevicelD OPTIONAL, 

[5] SEQUENCE OF TelephonyLocation OPTIONAL, 



-- List of cell locations used by this party during the service usage 
communicationTime [6] TimeSpan OPTIONAL, 

-- Time and duration of the communication 



iMSI 

natureOf Address 

-- Nature of address indicator, 
forwardedTransferredNumber 
terminatingTransferredNumber 



[8] IMSI OPTIONAL, 
[9] UTF8String OPTIONAL, 
e.g. "National", "International" 
[10] PartyNumber OPTIONAL, 
[11] PartyNumber OPTIONAL, 



emailAddress [12] UTF8String OPTIONAL, 

-- used for MMS that supports also the use of E-Mail addresses {RFC 5322 [24] ) 
iMEI [13] IMEI OPTIONAL, 

detailedLocation [14] TelephonyNetworlcElement OPTIONAL, 

-- In the case detailed location information per call and party is available 

-- {e.g. the geoCoordinates for this partyNumber) 
nationalTelephonyPartylnformation [15] NationalTelephonyPartylnformation OPTIONAL, 

-- To be defined on a national basis 

-- Only to be used in case the present document cannot fulfil the national requirements 
partyType [16] TelephonyPartyType OPTIONAL, 

dialledDigits [17] UTF8String OPTIONAL 



Nat ionalTelephonyPartyInf ormation 

{ 



SEQUENCE 



countryCode [1] UTF8String {SIZE {2)), 

-- see comment in NationalRequestParameters 
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TelephonyPartyType 

{ 

voicemail 
smsServer 
other 



:= CHOICE 

[1] NULL, 
[2] NULL, 
[3] UTFSString, 



TelephonyCommunicationType 

{ 

telephonyFixedCS (0) , 
telephonyWirelessCS (!) , 

sMS{2) , 



ENUMERATED 



mMS{3) 



TelephonyBearerService 

{ 

speech (0) , 
datad) , 
fax (2) , 



ENUMERATED 



Sms Information 



smsEvent 



SEQUENCE 

[1] ENUMERATED 



shortMessage (!) , 
shortPartMessage (2) , 
composlteMessage (3) , 
notlf IcatlonMessage (4 ) 



} OPTIONAL, 
smsType 



[2] ENUMERATED 



deliverSCtoMSd) , 
deliverReportMStoSC{2) , 
statusReportSCtoMS (3) , 
commandMStoSC (4) , 
submitMStoSC{5) , 
submitReportSCtoMS (6) , 
reservedMTIValue (7) , 



) OPTIONAL, 
smsStatus 



[ 3 ] ENUMERATED 



delivered{0) , 
expired (1) , 
deleted (2) , 
replaced (3) , 
submitted (4) , 
incomplete-submission (5) , 
incomplete-delivery (6) , 
undeliverable (7) , 
passed-on (8) , 

} OPTIONAL, 

smsCmRefNr [4] OCTET STRING {SIZE{1..2)) OPTIONAL, 

-- format as per 3GPP TS 23.040 [16] 
smsNumOfSM [5] INTEGER {0.. 65535) OPTIONAL, 
smsNotifyInd [6] BOOLEAN OPTIONAL, 
smsProtocolId [7] OCTET STRING {SIZE{1)) OPTIONAL, 

-- format as per 3GPP TS 23.040 [16] 
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Mmslnformation ::= SEQUENCE 

{ 

nimsEvent [1] ENUMERATED 

{ 

message (1) , 

notlflcatlonMessage (2) , 
deliveryReportMessage (3) , 
readReplyMessage (4) , 

} OPTIONAL, 

-- type of message exchanged 
nmsStatus [2] ENUMERATED 

{ 

delivered{0) , 
expired (!) , 
deleted (2) , 
replaced (3) , 
submitted (4) , 
undeliverable (5) , 
passed-on (6) , 
delivery-rejection (7) , 
delivery-forward (8) , 
delivery-copy (9) , 
submission-rejection (10) , 
submission- failure (11) , 

delivered- application (12) 

-- optional flag indicating MMS was retrieved using 

-- something other than mobile deivce e.g. web browser 
} OPTIONAL, 
mmsNotifInd [3] BOOLEAN OPTIONAL, 

-- indication that a delivery notification has been generated 
mmsMsgMod [4] ENUMERATED 

{ 

none { 1 ) , 
modified (2) , 
stripped (3) , 

} OPTIONAL, 

-- message modification indication for MMS 



Te 
{ 


lephonyE 


ventlnformation : : = SEQUENCE 




time 




[1] 


GeneralizedTime OPTIONAL, 




-- 


time 


when the event occurred 




type 




[2] 


TelephonyEventType 


OPTIONAL, 




-- 


type 


of 


event 






party 




[3] 


TelephonyPartyRole 


OPTIONAL, 




-- 


party to 


which the event is 


related 


} 


location 


[4] 


TelephonyLocation OPTIONAL, 



TelephonyEventType ::= CHOICE 

{ 

basicEventType 






[1] 


BasicEventType , 


callConferenceEventType 


[2] 


CallConferenceEventType, 


callForwardingEventType 


[3] 


CallForwardingEventType, 


messagingEventType 


[4] 


MessagingEventType, 


prepayServiceEventType 


[5] 


PrepayServiceEventType , 


nationalTelephonyEventType 


[6] 


NationalTelephonyEventType 


-- To be defined on a 


national basis 


-- Only to be used in 
} 


case 


the present document cannot fulfil the national requirements 



NationalTelephonyEventType : : = SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE (2)), 

-- see comment in NationalRequestParameters 
} 
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BasicEventType ::= ENUMERATED 

{ 

handover { 1 ) , 


hold (2) , 


retrieved) , 


suspend (4) , 


resume (5) , 


ect{6) , 


mpty{7) , 


mptyHold{8) , 


mptyRetrieve (9) , 


mptySplitdO) , 


uusKll) , 


uus2 (12) , 


uus3{13) , 


serviceSpeech (14) , 


serviceFax (15) , 


tpy Invoke (16) , 


tpyPrivateComm{17) , 


serviceActivation{18) , 


transit (19) , 


mSOriginating{2 0) , 


callForwarding{21) , 


mSTerminating (22) , 


callAttempt{23) , 


callStart{24) , 


callEnd{25) , 


cliWithheld{26) 

} 



CallForwardingEventType 

{ 



ENUMERATED 



cfuActivation (1) , 
cfuModif ication (2) , 
cfuDe-activation (3) , 
cfcNoReplyActivation (4) , 
cfcNoReplyModif ication (5) , 
cfcNoReplyDe-activation (6) , 
cfcBusyActivation (7) , 
cfcBusyModif ication (8) , 
cfcBusyDe-activation (9) , 
cfcOutOfRangeActivation (10) , 
cfcOutOfRangeModif ication (11) , 
cfcOutOfRangeDe-activation (12) , 
cfcUnavailableActivation (13) , 
cfcUnavailableModif ication (14) , 
cfcUnavailableDe- activation (15) , 
cfuFaxActivation (16) , 
cfuFaxModif ication (17) , 
cfuFaxDe-activation (18) , 



CallConferenceEventType 

{ 

confBeginSeizure (1) , 
confAdd{2) , 
confSplit{3) , 
conf Isolate (4) , 
confReattach (5) , 
conf Drop (6) , 
confBeginActive (7) , 



ENUMERATED 
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MessagingEventType ::= ENUMERATED 


I 


mSOriginatingSMSinMSCd) , 




mSTerminatingSMSinMSC{2) , 




shortMessageDelivery (3) , 




mMMessage (4) , 




mMNotification{5) , 




mMDeliveryReport (6) , 


} 


mMReadReply (7) , 



PrepayServiceEventType : : = ENUMERATED 
{ 



serviceActivation (1) , 



TelephonyLocation 

{ 



SEQUENCE 



telephonyNetworklD [1] TelephonyNetworklD OPTIONAL, 

-- ID of the network element location {e.g. Cell ID) 
timeSpan [2] TimeSpan OPTIONAL, 

-- Time span that this location was valid for 

nationalTelephonyLocation [3] NationalTelephonyLocation OPTIONAL 
-- To be defined on a national basis 
-- Only to be used in case the present document cannot fulfil the national requirements 



NationalTelephonyLocation : : = SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE {2)), 

-- see comment in NationalRequestParameters 



TelephonyPartyRole 

{ 



ENUMERATED 



originating-Party {0) , 
terminating- Party {!) , 
forwarded- to -Party {2) , 
originalCalled{3) , 
redirecting {4) , 
connected {5) , 
userProvidedCalling {6) , 
roaming {7) , 
translated {8) , 
singlePersonalNiimber {9) , 
smsOriginator {10) , 
smsRecipient {11) , 
smsOriginatorTrn {12) , 
smsRecipientTrn {13) , 

mmsOriginator {14) , 
mmsRecipient {15) , 
mmsOriginatorTrn {16) , 
mmsRecipientTrn {17) 



£75/ 



66 ETSI TS 102 657 V1.10.1 (2012-09) 



-- Device Data definitions 



Telephony-Device : : = SEQUENCE 

{ 

devicelDType [1] ENUMERATED 

-- Type of identifier for telephony device 

{ 

unknown { ) , 
imei (!) , 
macAddress (2) , 

} OPTIONAL, 

telephonyOevicelD [2] TelephonyDevicelD OPTIONAL, 

-- Unique identifier for this telephony device according to type of identifier 

subscriberlD [3] TelephonySubscriberld OPTIONAL, 

-- Identifier for a known user of this equipment. 

-- Usage of this parameter is subject to national legislation. 
nationalTelephonyOevice [4] NationalTelephonyDevice OPTIONAL 

-- To be defined on a national basis 

-- Only to be used in case the present document cannot fulfil the national requirements 



NationalTelephonyDevice : : = SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE (2)), 

-- see comment in NationalRequestParameters 



TelephonyDevicelD : : = OCTET STRING 






-- A unique identifier for the telephony device. 


For example. 


the IMEI number 


-- of a mobile handset 







Network Data definitions 



TelephonyNetworkElement : : = SEQUENCE 

{ 

telephonyNetworklD 




[1] TelephonyNetworklD OPTIONAL, 


cell Information 


[2] Location OPTIONAL, 


-- The Location information id 




validity 


[3] TimeSpan OPTIONAL, 


nationalTelephonyNetworkElement 


[4] NationalTelephonyNetworkElement OPTIONAL, 


-- To be defined on a national 


basis 


-- Only to be used in case the 


present document cannot fulfil the national requirements 


transmitterDe tails 

} 


[5] TransmitterDetails OPTIONAL 



NationalTelephonyNetworkElement : : = SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE (2)), 

-- see comment in NationalRequestParameters 



TelephonyNetworklD : : = OCTET STRING 

-- Unique identifier for this network element: e.g. a Cell ID 



£75/ 



67 ETSI TS 1 02 657 V1 .1 0.1 (201 2-09) 



TransmitterDetails ::= SEQUENCE 

{ 

alternativelD [1] UTFSString OPTIONAL, 

-- For use by CSPs with an alternative naming scheme for cells 

beamWidth [2] INTEGER OPTIONAL, 

-- beam width in degrees 

-- note that the beam bearing is given in the gsmLocation Azimuth field 

radiatedPower [3] INTEGER OPTIONAL, 

-- Effective radiated power in watts. 

antennaHeight [4] INTEGER OPTIONAL, 

-- Height of antenna from ground in metres 

range [5] INTEGER OPTIONAL, 

-- Indication of range or radius of cell or sector coverage, in metres 

-- Precise definition is to be decided on a national basis {e.g. distance 

-- at which some fixed percentage of calls are connected) 

frequency [6] INTEGER OPTIONAL, 

-- transmitter frequency in kHz 

technology [7] TransmitterTechnology OPTIONAL, 

nationalTransmitterDetails [8] NationalTransmitterDetails OPTIONAL, 



TransmitterTechnology ::= ENUMERATED 

{ 

gen2G{0) , 
gen3G{l) , 



NationalTransmitterDetails ::= SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE {2)), 

-- see comment in NationalRequestParameters 



Location information 



Location : : = SEQUENCE 

{ 

el64-Niimber [1] OCTET STRING {SIZE {1..25)) OPTIONAL, 

-- Coded in the same format as the ISUP location number {parameter 
-- field) of the ISUP {see EN 300 356 [7]) 
globalCelllD [2] OCTET STRING {SIZE {5.. 7)) OPTIONAL, 

-- See MAP format {see 3GPP TS 09.02 [8]) 
rAI [3] OCTET STRING {SIZE {6)) OPTIONAL, 

-- The Routeing Area Identifier {RAI) in the current SGSN is coded in accordance with 
-- 3GPP TS 24.008 [9] without the Routing Area Identification lEI {only the 
-- last 6 octets are used) 

GSMLocation OPTIONAL, 
UMTSLocation OPTIONAL, 
OCTET STRING {SIZE {7) ) OPTIONAL, 
3 octets {no. 1-3) 
2 octets {no. 4-5) 
2 octets {no. 6-7) 
{according to 3GPP TS 25.413 [31]) 
oldRAI [7] OCTET STRING {SIZE {6)) OPTIONAL, 

-- the "Routeing Area Identifier" in the old SGSN is coded in accordance with 

-- 3GPP TS 24.008 [9] without the Routing Area Identification lEI 

-- (only the last 6 octets are used) 

-- This parameter is duplicated from 3GPP TS 33.108 [11] 



gsmLocation 


[4] 


luntsLocation 


[5] 


sAI 


[6] 


- - format : 


PLMN-ID 


-- 


LAC 


-- 


SAC 



postalLocation [8] Addressinf ormation OPTIONAL, 
extendedLocation [9] ExtendedLocation OPTIONAL 
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GSMLocation 



CHOICE 



geoCoordinates 

{ 



[1] SEQUENCE 



latitude [1] UTFSString {SIZE {7 . . 10) ) OPTIONAL, 

-- format: XDDMMSS.SS 
longitude [2] UTFSString {SIZE {8 . . 11) ) OPTIONAL, 

-- format: XDDDMMSS.SS 
mapDatum [3] MapDatum OPTIONAL, 
azimuth [4] INTEGER {0..359) OPTIONAL, 

-- The azimuth is the bearing, relative to true north 



format: XDDMMSS.SS {on latitudes) or XDDDMMSS.SS {on longitudes) 



X 



seconds. 



DD or DDD 
MM 

SS.SS 
Example : 

latitude {short form) 
longitude {long form) 



N(orth) , S{outh), E{ast), W{est) 
degrees {numeric characters) 
minutes {numeric characters) 

the second part {.SS) is optional 



N502312 
E1122312 .1£ 



utmCoordinates 



[2] SEQUENCE 



{ 



utm-Zone [1] UTFSString {SIZE{3)) OPTIONAL, 
Utm-East [2] UTFSString {SIZE{6)) OPTIONAL, 
Utm-North [3] UTFSString {SIZE{7)) OPTIONAL, 
-- Universal Transverse Mercator 
-- example utm-Zone 32U 

Utm-East 439955 
Utm-North 5540736 
mapDatum [4] MapDatum OPTIONAL, 
azimuth [5] INTEGER {0..359) OPTIONAL, 



The azimuth is the bearing, relative to true north 



utmRefCoordinates 



[3] SEQUENCE 



utm-GridZone [1] UTFSString {SIZE{2)) OPTIONAL, 

-- numerals from 1 to 6 
utm-GridBand [2] UTFSString {SIZE{1)) OPTIONAL, 

-- character between C and X 
squarelD [3] UTFSString {SIZE{2)) OPTIONAL, 

-- characters from A to Z 
numericalLocationEasting [4] UTFSString {SIZE{5)) OPTIONAL, 
numericalLocationNorthing [5] UTFSString {SIZE {5)) OPTIONAL, 

-- Universal Transverse Mercator Reference = Military Grid Reference System {MGRS) 
-- example utm-GridZone 32 

Utm-GridBand U 

squarelD PU 

numericalLocationEasting 9129 
mumericalLocationNorthing 4045 
--In both panels, utm-GridBand and squarelD the 'I' and 'O' characters are not used 
-- because of their similarity to the digits one and zero. 
mapDatum [6] MapDatum OPTIONAL, 

azimuth [7] INTEGER {0..359) OPTIONAL, 

-- The azimuth is the bearing, relative to true north 



wGS84Coordinates [4] OCTET STRING, 

-- format is as defined in 3GPP TS 03.32 [12] 

geoCoordinatesDec [5] SEQUENCE 

{ 

latitudeDec [1] UTFSString {SIZE {3 . . 12) ) OPTIONAL, 

- - format : XDD . nnnnnnnn 

longitudeDec [2] UTFSString {SIZE {4 . . 13) ) OPTIONAL, 

- - format : XDDD . nnnnnnnn 

mapDatum [3] MapDatum OPTIONAL, 

azimuth [4] INTEGER {0..359) OPTIONAL, 

-- The azimuth is the bearing, relative to true north 



format 
X 
DD or DDD 

nnnnnnnn 



XDD. nnnnnnnn {on latitudes) or XDDD . nnnnnnnn {on longitudes) 
N{orth) , S{outh), E{ast), W{est) 
degrees {numeric characters) 
post decimal positions {numeric characters) 
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Example : 

latitude 
longitude 



N50 .38666667 
E112 .38671670 



MapDatiun 



ENUMERATED 



{ 



WGS84 (1) , 

-- World Geodetic System 1984 
WGS72 (2) , 
eD50{3) , 

-- European Datum 50 
rD { 4 ) , 

-- Rijks Driehoek (Netherlands) 
potsdaiiiDatiim{5) , 
datiimAustria (6) , 
eTRS89 (7) , 

-- European Terrestrial Reference System 1989 
nAD27 (8) , 

-- North American Datum 1927 
oSGB36{9) , 

-- Ordnance Survey of Great Britain 
OSNI52 (10) , 

-- Ordnance Survey of Northern Ireland 
tM65 (11) , 
iTM{12) , 

-- Irish Transverse Mercator 

CH1903 (13) 

-- Swiss reference system 



UMTSLocation ::= CHOICE 

{ 

point 




[1] GA-Point, 


pointWithUnCertainty 


[2] GA-PointWithUnCertainty, 


polygon 

} 


[3] GA-Polygon, 



GeographicalCoordinates : : = SEQUENCE 

{ 

latitudeSign [1] ENUMERATED 



north (0) 
south (1) 
} OPTIONAL, 
latitude 
longitude 



mapDatum 
azimuth 



[2] INTEGER {0.. 8388607) OPTIONAL, 

[3] INTEGER {- 83886 08 .. 8388607 ) OPTIONAL, 

[4] MapDatum OPTIONAL, 

[5] INTEGER {0..359) OPTIONAL 



The azimuth is the bearing, relative to true north 



GA-Point ::= SEQUENCE 

geographicalCoordinates 



[1] GeographicalCoordinates, 



GA-PointWithUnCertainty : : =SEQUENCE 



geographicalCoordinates 
uncertaintyCode 



[1] GeographicalCoordinates, 
[2] INTEGER {0 . .127) 



maxNrOfPoints 



GA-Polygon ::= SEQUENCE {SIZE {1 . .maxNrOf Points) ) OF GA- Polygon-Elements 
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GA-Polygon-Elements ::= SEQUENCE 

{ 

geographicalCoordinates [1] GeographicalCoordinates, 



ExtendedLocation : 

{ 

spot 


:= CHOICE 


[1] Spot, 


circle 


[2] Circle, 


region 


[3] Region, 


route 


[4] Route, 


} 





Spot : := CHOICE 

{ 

gsmLocation 
postalLocation 



[1] GSMLocation, 

[2] Addresslnformation, 



Circle : : = SEQUENCE 

{ 

centre 

radius 



[1] Spot, 

[2] HorizontalExtent, 



Region : : = SEQUENCE 

{ 

cornerMarks 

} 



[1] SEQUENCE OF Spot, 



Route : : = 


SEQUENCE 












1 
} 


routeMarks 
width 


[1] 
[2] 


SEQUENCE OF Spot 
HorizontalExtent 


OPTIONAL, 



HorizontalExtent 

-- metres 



General definitions 



Party-Number ::= UTFSString 

-- E.164 address of the party in international format 
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B.4 Schematic view of ASN.1 definitions 



telephonyRecord 

telephonySubscriber 

subscriberlD 
generic Subscriber Info 
telephony Subscriber Info 
subscribedTelephony Services 
L SubscribedTelephonyServices 

servicelD 

providerlD 

timeSpan 

registeredNumbers 

regis teredlCCID 

serviceType 

installationAddress 

connect ionDate 

IMS I 

carrier Preselect 

lineStatus 

allocatedDevicelDs 

pUKCode 

pUK2Code 

iMEI 

nat i ona 1 Te 1 ephony Subs crip tionlnfo 

paymentDetails 
national TelephonySubscriber Info 
telephonyBi 11 ingDe tails 
subscriberlD 
servicelD 
bill ingAddr ess 
billingldentif ier 
billingRecords 

L BillingRecords 
time 
place 
amount 
currency 
method 

nationalTelephonyBillingRecords 
transact ionID 
transact ionSt a tus 
national TelephonyBi 11 ingDe tails 
telephonyServiceUsage 
partyinf ormation 
L TelephonyPartylnf ormation 

partyRole 

partyNumber 

subscriberlD 

devicelD 

locations 

communicationTime 

IMS I 

natureOf Address 

f orwardedTransf erredNumber 

terminatingTransf erredNumber 

emailAddress 

iMEI 

detailedLocation 

national Tel ephony Party Information 

partyType 

dialledDigits 
communicationTime 
event Information 
L TelephonyEvent Information 

time 

type 

party 

location 
endReason 
communicationType 
bearers ervice 
sms Information 
ringDuration 
mms Information 

national TelephonyServiceUsage 
telephonyDevice 
devicelDType 
telephonyDevicelD 
subscriberlD 
national TelephonyDevice 
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L telephonyNetworkElement 

telephonyNetworklD 

cell Information 

validity 

national TelephonyNetworkElement 

transmitter Details 

NOTE: This figure should be regarded only as an aid to understanding. In the event of a discrepancy between this figure and 
the text of the ASN.1 specification the ASN.1 specification is the leading one. 

Figure B.1 : Schematic representations of the major ASN.1 structures for telephony 
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Annex C (normative): 

Service-specific details for asynchronous message services 



C.1 Scope 



Asynchronous messaging services cover asynchronous communications involving the intermediate storage of messages. 
This includes e-mail, webmail but excludes chat, which is synchronous, and excludes SMS. 

The facilities a user may expect to find are e.g.: 

• Post a message to recipient's server. 

• Receive messages on own server. 

• Retrieve messages from own server. 

• Store messages in server (IMAP). 

SMS is handled under "telephony services", and is excluded from this annex. 

Figure C.l illustrates the relations between subscribers and message service providers. It also illustrates the operations 
on message stores, and message transmissions (dotted lines). 
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Figure C.1 : Schematic overview of message handling 

When messages are delivered to a message server, the server will temporarily store that message in a store. At a later 
time, an authorized subscriber can access the message store, and retrieve the message. Subscribers can perform other 
operations on message stores, such as deleting or adding messages. 



C.2 Descriptions 
C.2.1 General 

This clause describes the fields and parameters of the Asynchronous Message ASN.l definitions given in clause C.3. 
This clause should be read in conjunction with the notes in the ASN.l definitions themselves. 
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C.2.2 MsgSubscriber 



This structure contains the information on the subscriber, and the subscribed services, independent on actual usage. 

Table C.I : MsgSubscriber parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


validity 


Time period during which the information given in this structure is or was 
valid. 





subscriberlD 


A unique identifier for this particular subscriber within the CSP. 





msgStores 


Descriptions of the private message stores associated with this 
subscriber. See clause C.2.4. 





subscriber 


Common information such as name and address is stored the 
GenericSubscriberlnfo structure. This is defined in the 
service-independent annex A. 


c 


paymentDetails 


Details for payment (e.g. associated bank account, billing method or 
billing address). 






C.2.2.1 MsgSubscriberlD 



A unique identifier for subscribers within a CSP. This could be an account name, subscriber number, or any other 
identification assigned by the CSP. 

C. 2.2.2 MsgStore 

This structure contains the information on a particular message store, including the addresses associated with this 
message store. 

Table C.2: MsgStore parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


Validity 


Time period during which the information given in this structure is or was 
valid. 





msgStorelD 


A unique identifier for this particular message store within the CSP. 





Aliases 


The complete list of all addresses that get delivered into this message 
store. This may (as a national option) include wildcard addresses 
(e.g. "©example. com"), meaning that all email to that domain is 
delivered into the message store. 


c 


providerlD 


A unique identifier of the provider hosting this message store. 






C. 2.2.3 MsgStorelD 



A unique identifier for message stores. This could be a mailbox name, or any other identification used by the CSP's 
message server. 



C.2.2.4 MsgAddress 



A messaging address, i.e. an address to which messages can be sent. In the case of Internet e-mail this will be an 
RFC 0822-style address [23]. Other messaging systems (e.g. X.400) use their own messaging addresses. 



C.2.2.5 MsgProvicderlD 



A unique identifier for messaging service providers. This could, for example, be the company name, or company 
registration number. 
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C.2.3 MsgServiceUsage 



This structure contains the information on the activities performed by a subscriber. There are two types of actions: those 
that manipulate message stores, and the sending of a new message. 

C.2.3. 1 MsgTransmission 

This structure contains all information on the sending of a message by a subscriber. For some services delivery failures 
result in a separate error message being returned to the sender. Bounced messages then result into two separate 
transmissions: the message sent by the subscriber and the error message sent by the remote message server. 

Table C.3: MsgTransmission parameters 



Field name 


Value 


IM/C/O 
(see clause A.I .1) 


dateTime 


Date and time when the subscriber submitted the message to the 
CSP's message server. 


C 


subscriberlD 


Unique identifier of the subscriber sending the message. 


C 


senderAddress 


The available address of the sender (see note). 


c 


recipients 


The list of all available recipients of the message (see note). 


c 


msgStores 


List of all local message stores that received a copy of the message. 
This is both relevant for incoming messages, and for outgoing 
messages that have a local recipient. 





deliveryStatus 


Result of the transmission from the CSP's message server towards 
the final destination. Final delivery may pass through a number of 
intermediate message servers. This field does not indicate the 
end-to-end delivery status. It indicates the status of the "next hop". 





protocol 


Message transmission protocol used. 





clientlD 


IP address of the source of the message transmission. 


c 


serverlD 


IP address of the destination of the message transmission. 





messagelD 


Unique identifier for the message - for example RFC 0822 [23] 
message-id header. 





sourceServerName 


Name for the server sending the message (if appropriate). 





destinationServerName 


Name for the server receiving the message (if appropriate). 





NOTE: Depending on implementation and national discussion, some addresses may not be available, or may not be 
checked or reliable. 



C. 2.3.2 MsgStoreOperation 

This structure contains all information on the manipulation of a message store by a subscriber. 

Table C.4: MsgStoreOperation parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


dateTime 


Date and time when the subscriber performed the indicated operation. 


C 


subscriberlD 


Unique identifier of the subscriber performing the operation. 


C 


msgStore 


Unique identifier of the message store being manipulated. 





operation 


Type of manipulation performed by the subscriber. 


c 


senderAddress 


The available address of the sender (see note). 


c 


recipients 


List of all the available recipients of the message (see note). 


c 


protocol 


IVIessage store manipulation protocol. 





clientID 


IP address of the subscriber who performed the indicated operation. 


c 


serverlD 


IP address of the message server hosting the message store being 
manipulated. 





messagelD 


Unique identifier for the message - for example RFC 0822 [23] 
message-id header. 





NOTE: Depending on implementation and national discussion, some addresses may not be available, or may not be 
checked or reliable. 



£75/ 



76 



ETSI TS 102 657 V1.10.1 (2012-09) 



C.2.4 MsgBillingDetails parameters 

The MsgBillingDetails structure contains billing information for the message service. 

Table C.5: MsgBillingDetails parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


subscriberlD 


A unique identifier for a particular subscriber within a CSP. 





servicelD 


A unique identifier witliin tlie operator for tlie service or tariff 
subscribed to. 





billingAddress 


The billing address for this subscription. 





billingldentif ier 


A unique identifier for billing purposes. The format of this field is 
for CSPs to determine. 





billingRecords 


A sequence of billing records, one for each payment by the 
subscriber on this subscription - see clause C.2.4. 1 . 





nationalMsgBillingDetails 


Defined on a national basis. 






C.2.4.1 MsgBillingRecords 

Each billing record contains information for a particular payment. The parameters are as follows. 

Table C.6: MsgBillingRecords parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


time 


Time of the payment. 





place 


Location of the payment. 





amount 


The amount of the payment, in currency specified. 





currency 


Currency of payment, in ISO 4217 [5] format. 





method 


Type of payment (e.g. credit card, top-up voucher). The format 
of this field is for agreement with the CSP. 





nationalMsgBillingRecords 


Defined on a national basis. 





msgTransactionID 


Unique reference for this transaction/billing record. 





msgTransactionStatus 


Status of the transaction (i.e. "declined", "succeeded", etc.). 








C.3 ASN.1 definitions for asynchronous message 
services 



MessageRecord ::= CHOICE 

{ 

msgSubscriber 




[1] MsgSubscriber, 


msgServlceUsage 


[2] MsgServlceUsage, 


msgBllllngDe tails 

} 


[3] MsgBillingDetails 



£75/ 



77 ETSI TS 1 02 657 V1 .1 0.1 (201 2-09) 



-- Definitions of Message Subscriber Data 



MsgSubscriber : : = SEQUENCE 

-- Generic information on a service subscriber, supplemented with information specific to 
- asynchronous message services 



{ 



validity [1] TimeSpan OPTIONAL, 

subscriberlD [2] MsgSubscriberlD OPTIONAL, 

msgStores [3] SEQUENCE OF MsgStore OPTIONAL, 

-- message stores allocated to this subscriber 

subscriber [4] GenericSubscriberlnfo OPTIONAL, 

paymentOetails [5] PaymentOetails OPTIONAL 



MsgSubscriberlD ::= OCTET STRING 

-- Unique identifier for this subscriber, e.g. account number 



MsgStore : : = SEQUENCE 

-- Location into which messages are temporarily stored. All asynchronous message services by 
-- definition require some message store. E.g. in the case of e-mail this will be a mailbox 

{ 

validity [1] TimeSpan OPTIONAL, 

msgStorelD [2] MsgStorelD OPTIONAL, 

aliases [3] SEQUENCE OF MsgAddress OPTIONAL, 

-- The complete list of all addresses that get delivered into this message store. 
providerlD [4] MsgProviderlD OPTIONAL, 



MsgStorelD : : = OCTET STRING 




-- Unique identifier of the message store. Since not 


all IDs will necessarily be human 


-- readable, a generic byte string is used 





MsgAddress 


: := UTFSSt 


ring 




























-- Messaging 


addre 


3S, an address 


to which messages 


can 


be 


sent . 


In 


the 


case 


of 


Internet 


e 


-mail 


-- this 


will 


be an 


RFC822-style 


address 
























-- NOTE 


- as 


of vl 


.2.1, this fie 


Id has 


changed 


from 


OCTET 


STRING 


to 


UTFSString 









MsgProviderlD 


: : = UTFSString 




- - Unique 


identifier for a service provider, e.g. company 


name 


-- NOTE - 


as of vl.2.1, this field has changed from OCTET 


STRING to UTFSString 



Definitions of Message Service Usage 



MsgServiceUsage ::= CHOICE 

-- Choice of different types of activities 

-- Manipulation of stored address books is outside the scope 

{ 

msgTransmission [1] MsgTransmission, 
msgStoreOperation [2] MsgStoreOperation, 
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MsgTransmission ::= SEQUENCE 

-- Sending of an outgoing message, or reception of an incoming message 

{ 

dateTime [1] GeneralizedTime OPTIONAL, 

subscriberlD [2] MsgSubscriberlD OPTIONAL, 

senderAddress [3] MsgAddress OPTIONAL, 

recipients [4] SEQUENCE OF MsgAddress OPTIONAL, 

msgStores [5] SEQUENCE OF MsgStorelD OPTIONAL, 

-- List of all local msgStores that received a copy of the message 

-- For transit messages this field is not used 

delivery-Status [S] ENUMERATED 

{ 

unknown { ) , 
succeeded (1) , 

-- Delivery might still fail at a subsequent mail server 
failed{2) , 

-- E.g. when mailbox quota exceeded {mailbox full) 
retried (3) , 

-- Deferred and retried at a later time 

} OPTIONAL, 

protocol [7] ENUMERATED 

{ 

smtp { ) , 
x400{l) , 

} OPTIONAL, 

clientlD [8] IPAddress OPTIONAL, 

serverlD [9] IPAddress OPTIONAL, 

messagelD [10] MessagelD OPTIONAL, 

sourceServerName [11] UTFSString OPTIONAL, 
destinationServerName [12] UTFSString OPTIONAL 



MsgStoreOperation : : = SEQUENCE 

-- Manipulation of a message store. 

{ 

dateTime [1] GeneralizedTime OPTIONAL, 

subscriberlD [2] MsgSubscriberlD OPTIONAL, 

msgStore [3] MsgStorelD OPTIONAL, 

operation [4] ENUMERATED 

{ 

connect (0) , 

-- Successful authorization for access to msgStore 
disconnect (1) , 
retrieveMsg (2) , 

-- Viewing msg using a webmail client is also considered retrieval 
partialretrieveMsg (3) , 

-- E.g. the TOP command in P0P3 
deleteMsg(4) , 
addMsg { 5 ) , 

-- E.g. the APPEND command in IMAP 

editMsg{6) 

} OPTIONAL, 

senderAddress [5] MsgAddress OPTIONAL, 

-- For Internet email, use the From address in the mail headers 

recipients [6] SEQUENCE OF MsgAddress OPTIONAL, 

-- For Internet email, use the To, CC, and BCC addresses in the mail headers 

protocol [7] ENUMERATED 

{ 

pop { ) , 

imap { 1 ) , 

webmail (2) 

} OPTIONAL, 

clientID [8] IPAddress OPTIONAL, 

serverlD [9] IPAddress OPTIONAL, 



messagelD [10] MessagelD OPTIONAL 



MessagelD ::= UTFSString 

-- Unique identifier for this message, e.g RFC 822 header 
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-- Definitions of Billing Data 



MsgBillingOetails ::= SEQUENCE 

{ 

subscriberlD 






[1] 


MsgSubscriberlD OPTIONAL, 


servicelD 


[2] 


UTFSString OPTIONAL, 


bill ingAddr e s s 


[3] 


ContactOetails OPTIONAL, 


billingldentif ier 


[4] 


MsgBillingldentifier OPTIONAL, 


billingRecords 


[5] 


SEQUENCE OF MsgBillingRecords OPTIONAL, 


nationalMsgBillingOe tails 


[S] 


NationalMsgBillingOetails OPTIONAL, 


-- To be defined on a 


national basis 


-- Only to be used in 
} 


case 


the present document cannot fulfil the national requirements 



NationalMsgBillingOetails 

{ 



SEQUENCE 



country-Code [1] UTFSString {SIZE (2)), 

-- see comment in NationalRequestParameters 



MsgBillingldentifier ::= OCTET STRING 

-- Used to correlate billing information 

-- useful if the bill-payer is not the subscriber, e.g. company mobiles 



MsgBi 1 1 ingRecords 

{ 



SEQUENCE 



[1] GeneralizedTime OPTIONAL, 

[2] UTFSString OPTIONAL, 

[3] REAL OPTIONAL, 

[4] UTFSString {SIZE{3)) OPTIONAL, 

[5] UTFSString OPTIONAL, 



time 
place 
amount 
currency 

-- as per ISO 4217 [5] 
method 

-- i.e. credit card etc. 
nationalMsgBillingRecords [6] NationalMsgBillingRecords OPTIONAL, 

-- To be defined on a national basis 

-- Only to be used in case the present document cannot fulfil the national requirements 

msgTransactionID [7] UTFSString OPTIONAL, 

-- Unique reference for this transaction/billing record 

-- Details to be defined on a national basis 
mgsTransactionStatus [S] UTFSString OPTIONAL 

-- Status of the transaction {i.e. "declined", "succeeded" etc.) 

-- Details to be defined on a national bases 



NationalMsgBillingRecords ::= SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE {2)), 

-- see comment in NationalRequestParameters 
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C.4 Schematic view of ASN.1 definitions 

MessageRecord 
msgSubscrlber 

validity 
subscriberlD 
msgStores 
L MsgStore 

- validity 

- msgStorelD 

- aliases 
^ providerlD 

subscriber 
^ paymentDetails 
- msgServiceUsage 

msgTransmission 
dateTime 

- susbcriberlD 

- senderAddress 

- recipients 

- msgStores 
deliveryStatus 
protocol 
clientlD 
serverlD 

- messagelD 

- sourceServerName 
destinationServerName 

msgStoreOperation 
dateTtime 
subscriberlD 
msgStore 
operation 
s ende r Addr e s s 

- recipients 

- protocol 

- clientID 

- serverlD 
^ messagelD 

msgBl 11 IngDe tails 
subscriberlD 
servicelD 

- billingAddress 

- billingldentif ier 

- billingRecords 
^ MsgBillingRecords 

time 
place 
amount 
currency 

- method 

- nationalMsgBillingRecords 

- msgTransactionID 
msgTransactionStatus 

^ nationalMsgBillingDetails 

NOTE: This figure should be regarded only as an aid to understanding. In the event of a discrepancy between this figure and 
the text of the ASN.1 specification the ASN.1 specification is the leading one. 

Figure C.2: Schematic representations of thie major ASN.1 structures for asyncfironous messaging 
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Annex D (normative): 

Service-specific details for synchronous multi-media 

services 



D.1 Scope 



Synchronous multimedia services covers those services offering the facilities listed below. It covers services that 
provides VoIP and MoIP functionality. Carrier class VoIP could also be covered by annex B if no IP layer information 
is needed. 

A user may expect a service that offers the capability e.g. to: 

Initiate communication set up. 

Accept communication set up. 

Conduct communication with one or more other parties. 

Cancel communication. 

Use a basic set of value-added services. 

NOTE: Multimedia services cover services provided via IMS 3GPP TS 23.228 [25]. 



D.2 Multimedia fields 
D.2.1 General 

This clause described the fields and parameters of the Multimedia ASN.l definitions given in clause D.3. This clause 
should be read in conjunction with the notes in the ASN.l definitions themselves and the definitions in clauses A. 1.1 
and B.3. 

D.2. 2 Multimedia Subscriber 

This structure contains the information on the subscriber, and the subscribed services, independent of actual usage. 

Table D.1 : MultimediaSubscriber parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


subscriberlD 


A unique identifier for this particular subscriber within the 
CSP. 





genericSubscriberInf o 


General personal information defined in annex A. 





multimediaSubscriberlnf o 


Service specific information about the subscriber. 





subscribedMultimediaServices 


List of services details that a subscriber (or account) may 
have. 






D. 2.2.1 subscriberlD 

subscriberlD is a unique identifier for a particular subscriber within a CSP, for example an account number. The format 
and content of this field is for CSPs to determine. The only requirement is that the subscriber ID is unique for each 
subscriber within the CSP. 
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D.2.2.2 genericSubscriberlnfo 

Common information such as name and address is stored in the genericSubscriberlnfo structure. This is defined in the 
service-independent annex A. 

D.2.2.3 multimediaSubscriberlnfo 

Information about the subscriber which is specific to multimedia services is contained in the muhimediaSubscriberlnfo 
structure. This is for further study. 

D.2.2.4 subscribecJMultimecJiaServices 
D.2.2.4.1 Description 

There shall be a subscribedMultimediaServices structure for each subscription the subscriber holds. The parameters are 
as follows. 

Table D.2: SubscribedMultimediaServices parameters 



Field name 


Value 


M/C/0 

(see clause 

A.1.1) 


servicelD 


A unique identifier within tlie operator for tfie service or tariff 
subscribed to. 





providerlD 


A unique identifier for the service provider. The format of this 
field is to be determined by national agreement. 





timeSpan 


Time over which the subscription was held. If the subscription 
is active, the endTime shall not be populated. 





registeredldentif iers 


The multimedia identifiers(s) assigned to the subscriber as part 
of this subscription, if applicable. 





regis teredlCCID 


Integrated Circuit Card ID (ICCID) number of the subscriber, in 
ASCII format. 





serviceType 


The type of service subscribed to. 





installationAddress 


The installation address for the subscriber's equipment, if 
applicable. 





connect ionDate 


Date that the subscription was actually connected (may be 
different to the start of the subscription). 





iMSI 


IIVISI associated with the subscriber. 





carrierPreselect 


Flag to indicate that the subscriber has carrier preselect active. 





lineStatus 


CSP-specific description of current line or subscription status 
e.g. "Active", "Suspended" etc. 





nationalMultimediaServices 


Defined on a national basis. 





paymentDetails 


Details for payment (e.g. associated bank account, billing 
method or billing address). 
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D.2.3 MultimediaBillingDetails 
D.2.3.1 MultimediaBillingDetails 

The MultimediaBillingDetails structure gives information about the subscribers billing history for a particular 
subscription. The parameters are as follows. 

Table D.3: MultimediaBillingDetails parameters 



Field name 


Value 


M/C/0 

(see clause 

A.1.1) 


subscriberlD 


A unique identifier for a particular subscriber within a 
CSP. 





servicelD 


A unique identifier within the operator for the service or 
tariff subscribed to. 





billingAddress 


The billing address for this subscription. 





billingldentif ier 


A unique identifier for billing purposes. The format of 
this field is for CSPs to determine. 





billingRecords 


A sequence of billing records, one for each payment by 
the subscriber on this subscription - see clause D.2.3. 2. 





nationalMultimediaBillingDetails 


Defined on a national basis. 






D.2.3.2 MultimediaBillingRecords 

Each billing record contains information for a particular payment. The parameters are as follows. 

Table D.4: MultimedaBillingRecords parameters 



Field name 


Value 


M/C/0 
(see clause A.1.1) 


time 


Time of the payment. 





place 


Location of the payment. 





amount 


The amount of the payment, in currency specified. 





currency 


Currency of payment, in ISO 4217 [5] format. 





method 


Type of payment (e.g. credit card, top-up voucher). The 
format of this field is for agreement with the CSP. 





nationalMultimediaBillingRecords 


Defined on a national basis. 





multimediaTransactionlD 


Unique identifier for the billing transaction. 





multimediaTransactionStatus 


Status of the billing transaction. 
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D.2.4 Multimedia ServiceUsage 
D.2.4.1 Parameters 

The MultimediaServiceUsage structure is used for service usage information, such as call data records. The parameters 
are as follows. 

Table D.5: MultimediaServiceUsage parameters 



Field name 


Value 


M/C/0 

(see clause 

A.1.1) 


partyinf ormation 


A list of partylnformation structures (see clause D.2.4. 2). 


C 


communicationTime 


Total time for this service usage. Not that the time of 
involvement of individual parties may be shorter (see 
clause D.2.4.2). 


C 


reasonCause 


Cause code for end of call, e.g. encoded SIP Reason 
Cause codes. 





communicationType 


Type of bearer service used in the session. 


C 


bearerService 


The bearer service for the communication. 


C 


qualityOf Service 


The quality of service parameter for the communication. 





ringDuration 


Ring duration, given in seconds for VoIP. 





calllD 


Identifier of the retained call data, e.g. SIP calllD, for 
correlating data from different DR sources in CSP. 





originalCalllD 


Identifier of the retained call data before any modification 
made by the node and usable to correlate data by different 
DR sources in CSP. 





callState 


State reached by the session with reference to the called 
subscriber connection, e.g. b not reached, b alerted, b 
answered. 





answerTime 


Date and time when the communication has been 
answered by the called party in case of sessions. 





contentType 


List of the media type of the message body, 
e.g. application/sdp, text/html. 





mediaComponents 


List of media component changes during the session. 





ims Information 


llVIS-specific information. 





nationalMultimediaServiceUsage 


Defined on a national basis. 





servicelD 


A unique identifier within the operator for the service or 
tarif. 





providerlD 


A unique identifier for the service provider. The format of 
this field is to be determined by national agreement. 
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D.2.4.2 Party Information 

A Partylnformation structure is filled in for each party involved in the communication. The parameters are as follows. 

Table D.6: Partylnformation parameters 



Field name 


Value 


M/C/0 

(see clause 

A.1.1) 


partyRole 


Role for this party (e.g. called, calling). 


C 


partyldentity 


Identifier for this party. URI is used in case of IMS 
service. 


C 


subscriberlD 


Subscriber identifier, unique identifier for subscriber 
(see clause D.2.2.1). 





communicationTime 


Time that this party was involved in the communication, if 
this was a multiparty communication. Shall be omitted if it 
is the same as the time of the whole service usage 
(see clause D. 2.4.1). 





iMSI 


IMSI associated with the party, if available. 





natureOf Address 


Nature of the address - may be "International number", 
"national number" or "subscriber number". 





uRI 


URI of the party. 





partyNumber 


E.I 64 number associated to party. 





naAs s ignedAddres s 


Address used by the subscriber's client for the 
connection. 





f orwardedTransf erredldentif ier 


Forwarded Identifier if communication was transferred. 





terminatingTransf erredldentif ier 


Terminating identifier if communication was transferred. 





nationalMultimediaParty Information 


Defined on a national basis. 





userAgent 


User agent field, e.g. SIP user agent, see RFC 3261 [26]. 





octet sUploaded 


Number of uploaded octets. 





octet sDownloaded 


Number of downloaded octets. 






D. 2.4.3 IMSInformation 

This Imslnformation structure is used for service usage information in case of IMS service; the parameters are as 
follows. 

Table D.7: IMSInformation parameters 



Field name 


Value 


M/C/0 
(see clause A.1.1) 


service 


Type of IMS service used by subscriber, e.g. session, message, refer. 





roleOfNode 


Specification on the role of the Data Retention Source in the reported 
communication, e.g. originating, terminating, proxy, b2bus. 





serviceinf o 


List of service-specific data. 






D.2.4.4 MediaComponents 

This structure contains the information on media components. 
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Table D.8: MediaComponent parameters 



Field name 


Value 


M/C/0 

(see clause 

A.1.1) 


time 


Time when this media component has been processed. 





mediaName 


IVIedia component name (from "m=" line in SDP data). 





mediaDescription 


IVIedia component description (from "attribute-line" 
content in SDP data). 





medialnitiator 


Media component initiator, i.e. called Party, calling 
Party. 





accessCorrelationID 


Correlation identifier for the access used for SIP usage. 





nationalMultimediaMediaComponent 


Defined on a national bases. 
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D.3 ASN.1 definitions for IVIuIti media 



MultimediaRecord ::= CHOICE 

{ 

multimediaSubscriber 






[1] 


MultimediaSubscriber, 


multimediaBillingDetails 


[2] 


MultimediaBillingDetails , 


multimediaServiceUsage 

} 


[3] 


MultimediaServiceUsage, 



Definitions of Subscriber Data 



MultimediaSubscriber ::= SEQUENCE 

{ 

subscriberlD [1] MultimediaSubscriberlD OPTIONAL, 

-- unique identifier for this subscriber, e.g. account number 
genericSubscriberlnfo [2] GenericSubscriberlnfo OPTIONAL, 

-- generic personal information about this subscriber 
multimediaSubscriberlnfo [3] MultimediaSubscriberlnfo OPTIONAL, 

-- service-specific information about this subscriber 
subscribedMultimediaServices [4] SEQUENCE OF SubscribedMultimediaServices OPTIONAL, 

-- a subscriber {or account) may have more than one service listed against them 

} 



MultimediaSubscriberlnfo ::= SEQUENCE 

{ 

nationalMultimediaSubscriberlnfo [1] NationalMultimediaSubscriberlnfo OPTIONAL, 



MultimediaSubscriberlD ::= UTFSString 

-- unique identifier for this subscriber, e.g. account number 



SubscribedMultimediaServices ::= SEQUENCE 

{ 

servicelD [1] UTFSString OPTIONAL, 

-- Unique identifier for this service within the operator 
providerlD [2] UTFSString OPTIONAL, 

-- Unique identifier for the service provider 
timeSpan [3] TimeSpan OPTIONAL, 

-- Start and end data, if applicable, of the subscription 
registeredldentifiers [4] SEQUENCE OF Partyldentity OPTIONAL, 

-- The set of identifiers registered for this service 
registeredlCCID [5] UTFSString OPTIONAL, 

serviceType [S] MultimediaServiceType OPTIONAL, 

installationAddress [7] Addresslnformation OPTIONAL, 

-- installation address, if different from the registered address 
connectionDate [S] GeneralizedTime OPTIONAL, 

-- Date the subscriber was actually connected 

-- {May differ from the start of subscription) 
iMSI [9] IMSI OPTIONAL, 

carrierPreselect [10] BOOLEAN OPTIONAL, 

lineStatus [11] UTFSString OPTIONAL, 

-- CSP-specific description of current line status, 

-- e.g. "Active", "Ceased", etc. 
nationalMultimediaServices [12] NationalMultimediaServices OPTIONAL, 

-- national extension 

paymentDetails [13] PaymentDetails OPTIONAL 



MultimediaServiceType ::= ENUMERATED 

{ 

private {0) , 
privatePABX{l) , 
publicPayphone {2) , 
geographicalf ixed{3) , 
geographicalindependent {4) , 
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Definitions of Service Usage Data 



MultimediaServiceUsage 

{ 

partylnformation 


: : = 


SEQUENCE 










[1] 


SEQUENCE OF MultimediaPartylnf ormation OPTIONAL, 


-- This parameter provides 


the concerned party {Originating, Terminating or 


-- forwarded party) 


, the identity (ies) of the party and all the information 


-- provided by 


the 


party 






conmunicationTime 






[2] 


TimeSpan OPTIONAL, 


-- Time and duration of the 


communication 


reasonCause 






[3] 


INTEGER OPTIONAL, 


-- cause code f 


or call termination e.g. SIP Reason code 


communicationType 






[4] 


MultimediaCommunicationType OPTIONAL, 


bearerService 






[5] 


MultimediaBearerService OPTIONAL, 


qualityOf Service 






[6] 


QualityOf Service OPTIONAL, 


ringOuration 






[7] 


INTEGER OPTIONAL, 


calllD 






[8] 


MultimediaCalllD OPTIONAL, 


originalCalllD 






[9] 


MultimediaCalllD OPTIONAL, 


callState 

{ 

bNotReachedd) , 






[10] 


ENUMERATED 










bAlert{2) , 










bAnswered { 3 ) , 










} OPTIONAL, 










answerTlme 






[11] 


GeneralizedTime OPTIONAL, 


contentType 






[12] 


SEQUENCE OF UTFSString OPTIONAL, 


medlaComponents 






[13] 


SEQUENCE OF MediaComponent OPTIONAL, 


ims Information 






[14] 


Imsinf ormation OPTIONAL, 


nationalMultimediaS 


erviceUsage 


[15] 


NationalMultimediaServiceUsage OPTIONAL, 


servicelD 






[16] 


UTFSString OPTIONAL, 


providerlD 

} 






[17] 


UTFSString OPTIONAL, 



MultimediaPartylnformation ::= SEQUENCE 

{ 

partyRole 




[1] MultimediaPartyRole OPTIONAL, 


partyldentity 


[2] Partyldentity OPTIONAL, 


subscriberlD 


[3] MultimediaSubscriberlD OPTIONAL, 


conmunicationTime 


[4] TimeSpan OPTIONAL, 


-- Time and duration of the communication 


iMSI 


[6] IMSI OPTIONAL, 


natureOfAddress 


[7] UTFSString OPTIONAL, 


-- Nature of address indicator. 


e.g. "National", "International" 


uRI 


[S] UTFSString OPTIONAL, 


partyNiimber 


[9] PartyNumber OPTIONAL, 


naAs s ignedAddr e s s 


[10] NAAssignedAddress OPTIONAL, 


forwardedTransferredldentif ier 


[11] Partyldentity OPTIONAL, 


terminatingTransferredldentif ier 


[12] Partyldentity OPTIONAL, 


nationalMultimediaPartyInf ormation 


[13] NationalMultimediaPartylnformation OPTIONAL, 


userAgent 


[14] UTFSString OPTIONAL, 


-- e.g. SIP User-Agent field {see RFC 3261 [26]) 


octetsUploaded 


[15] INTEGER OPTIONAL, 


octetsDownloaded 

} 


[16] INTEGER OPTIONAL 



MultimediaCalllD 



UTFSString 



MultimediaCommunicationType ::= ENUMERATED 

{ 

multimediaFixed{0) , 
multimediaWireless {1) , 
multimediaNetworklndependent {2) , 
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MultimediaPartyRole ::= ENUMERATED 

{ 

calling{0) , 
calledd) , 

calledAssertedldentity (2) , 
calledApplicationServer (3) , 
originalCalled{4) , 
redirecting (5) , 

multimediaNetworklndependent (6) 
directory (7) , 
broadcastReceiver (8) , 
broadcastSender (9) , 



MultimediaBearerService 



ENUMERATED 



{ 



speech (0) , 
datad) , 
fax (2) , 
video (3) , 
emergencyCall (4) , 



Ims Information 



{ 



service 

{ 

session (1) , 
message (2) , 

refer (3) , 

} OPTIONAL, 
roleOfNode 

{ 

originating { 1 ) 
terminating { 2 ) 
proxy (3) , 
b2bua{4) , 

} OPTIONAL, 
servicelnfo 



SEQUENCE 

[1] ENUMERATED 



[2] ENUMERATED 



[4] SEQUENCE OF ImsServiceInf o OPTIONAL, 



ImsServicelnfo 



SEQUENCE 



{ 



serviceData [1] OCTET STRING OPTIONAL, 

-- service data 
serviceType [2] INTEGER OPTIONAL, 

-- service type 



MediaComponent : : = SEQUENCE 

{ 

time 






[1] 


GeneralizedTime OPTIONAL, 


mediaName 


[2] 


UTFSString OPTIONAL, 


mediaDescription 


[3] 


UTFSString OPTIONAL, 


medialnitiator 


[4] 


Partyldentity OPTIONAL, 


accessCorrelationID 


[5] 


OCTET STRING OPTIONAL, 


nationalMultimediaMediaComponent 

} 


[S] 


NationalMultimediaMediaComponent OPTIONAL, 
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-- Definitions of Billing Data 



MultlmediaBlllingDe tails 

{ 



SEQUENCE 



subscriber ID 

servicelD 

bill ingAddr e s s 

billingldentif ier 

billingRecords 

nationalMultimediaBillingDe tails 

-- To be defined on a national basis 

-- Only to be used in case the present document cannot fulfil the national requirements 



[1] MultimediaSubscriberlD OPTIONAL, 

[2] UTFSString OPTIONAL, 

[3] ContactOetails OPTIONAL, 

[4] MultimediaBillingldentif ier OPTIONAL, 

[5] SEQUENCE OF MultimediaBillingRecords OPTIONAL, 

[6] NationalMultimediaBillingOetails OPTIONAL, 



NationalMultimediaBillingDetails ::= SEQUENCE 

{ 

country-Code [1] UTFSString {SIZE (2)), 

-- see comment in NationalRequestParameters 



MultimediaBillingldentif ier ::= OCTET STRING 
-- Used to correlate billing information 
-- useful if the bill-payer is not the subscriber, e.g. company mobiles 



MultimediaBillingRecords 

{ 



SEQUENCE 



[1] GeneralizedTime OPTIONAL, 

[2] UTFSString OPTIONAL, 

[3] REAL OPTIONAL, 

[4] UTFSString {SIZE{3)) OPTIONAL, 

[5] UTFSString OPTIONAL, 



time 
place 
amount 
currency 

-- as per ISO 4217 [5] 
method 

-- i.e. credit card etc. 
nationalMultimediaBillingRecords [6] NationalMultimediaBillingRecords OPTIONAL, 

-- To be defined on a national basis 

-- Only to be used in case the present document cannot fulfil the national requirements 

multimediaTransactionlD [7] UTFSString OPTIONAL, 

-- Unique reference for this transaction/billing record 

-- Details to be defined on a national basis 
multimediaTransactionStatus [S] UTFSString OPTIONAL 

-- Status of the transaction {i.e. "declined", "succeeded" etc.) 

-- Details to be defined on a national bases 



NationalMultimediaBillingRecords ::= SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE {2)), 

-- see comment in NationalRequestParameters 



General definitions 



Partyldentity ::= UTFSString 

-- E.164 address of the party in international format, or 
-- SIP URI or TEL URI representing E.164 



QualityOf Service ::= UTFSString 

-- Free text description of the invoked quality of service 



Nat ionalMultimediaSubscriber Info 



SEQUENCE 



countryCode [1] UTFSString {SIZE {2)), 

-- see comment in NationalRequestParameters 
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NationalMultimediaServices ::= SEQUENCE 

{ 

country-Code [1] UTFSString {SIZE (2)), 

-- see comment in NationalRequestParameters 



NatlonalMultlmedlaServlceUsage 

{ 



SEQUENCE 



country-Code [1] UTFSString {SIZE (2)), 

-- see comment in NationalRequestParameters 



NationalMultimediaPartylnformation ::= SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE {2)), 

-- see comment in NationalRequestParameters 



NationalMultimediaMediaComponent ::= SEQUENCE 

{ 

countryCode [1] UTFSString {SIZE {2)), 

-- see comment in NationalRequestParameters 
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D.4 Schematic view of ASN.1 definitions 

multimediaRecord 

multimediaSubscriber 

subscriberlD 
generic Subscriber Info 
multimediaSubscriber Info 
subscribedMultimediaServices 
L SubscribedMultimediaServices 
servicelD 
providerlD 
timeSpan 

registeredldentif iers 
register edICCID 
serviceType 
installationAddress 
connect ionDate 
iMSI 

carrierPreselect 
lineStatus 

nationalMultimediaServices 
paymentDe tails 
multimediaBillingDe tails 
subscriberlD 
servicelD 
bill ingAddr ess 
billingldentif ier 
billingRecords 
L MultimediaBillingRecords 
time 
place 
amount 
currency 
method 

nationalMultimediaBillingRecords 
multimediaTr ansae tionID 
multimediaTr ansae tionStatus 
nationalMultimediaBillingDetails 
multimediaServiceUsage 
- partyinf ormation 

L MultimediaPartylnf ormation 
partyRole 
party Identity 
subscriberlD 
communicationTime 
iMSI 

natureOf Address 
uRI 

partyNumber 
naAs s ignedAddr es s 
f orwardedTransf erredldentif ier 
terminatingTransf erredldentif ier 
nationalMultimediaParty Information 
userAgents 
octet sUploaded 
octet sDownloaded 
communicationTime 
reasonCause 
communicationType 
bearers ervice 
qualityOf Service 
ringDuration 
calllD 

original CalllD 
callState 
answerTime 
contentType 
mediaComponents 
time 

mediaName 
mediaDe script ion 
medialnitiator 
access Cor relationID 
nationalMultimediaMediaComponent 
ims Information 

nationalMultimediaServiceUsage 
servicelD 
providerlD 

NOTE: This figure should be regarded only as an aid to understanding. In the event of a discrepancy between this figure and 
the text of the ASN.1 specification the ASN.1 specification is the leading one. 

Figure D.1 : Schematic representations of the major ASN.1 structures for multimedia services 
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Annex E (normative): 

Service-specific details for network access services 



E.1 Scope 



Network access services covers the services offering a capability to access public data networks (typically the internet), 
including GPRS/UMTS-PS. 

Network access is typically provided by ISPs, possibly through an intermediate access provider, such as Cable-TV or 
ADSL. This may be taken as a generic capability to access public networks with a variety of protocols, but in current 
practice only Internet access would be of interest for data retention. 

User facilities are: 

• Access to the Internet, after some sort of authentication. 



E.2 Descriptions 
E.2.1 General 

This clause describes the fields and parameters of the Network Access ASN.l definitions given in clause E.3. This 
clause should be read in conjunction with the notes in the ASN.l definitions themselves. 

E.2.2 NASubscriber 

This structure contains the information on the subscriber, and the subscribed services, independent of actual usage. 

Table E.I : NASubscriber parameters 



Field name 


Value 


M/C/0 
(see clause A.1.1) 


validity 


Time period during which the information given in this structure is or 
was valid. 





subscriberlD 


A unique identifier for this particular subscriber within the CSP. 


C 


naSubscriptions 


List of all known services subscribed to by this user with this CSP. 





allocatedDevicelDs 


List of all known devices allocated to this user. The user may use 
other devices in addition (or instead of) these devices. 





subscriber 


Common information such as name and address is stored the 
GenericSubscriberlnfo structure. This is defined in the 
service-independent annex A. 


C 
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E.2.3 NAServiceSubscription 

This structure contains the information on a particular subscription by a subscriber. 

Table E.2: NAServiceSubscription parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


validity 


Time period during whicli the information given in this structure is or 
was valid. 





naServicelD 


A unique identifier for the type of service, e.g. account plan name. 





naProviderlD 


A unique identifier for the network access provider, e.g. company 
name or company registration number. 





naAuthID 


A unique identifier for this particular subscription, e.g. logon name. 


c 


options 


An optional human readable text with restrictions or options to the 
subscription, e.g. "fixed IP address; max 50 hr/month". 





installationAddress 


The installation address of the subscriber's equipment, if applicable. 





f ixIpAddress 


If the CSP assigns a fixed IP address to the subscriber (i.e. not 
allocated each time the service is used), then this IP address may 
be populated here. 





imsi 


If the CSP assigns an IMSI to the subscriber, this may be populated 
here. 





allocatedDevicelDs 


List of all known devices allocated to this user for this subscription. 
The user may use other devices in addition (or instead of) these 
devices. 





naServiceStatus 


CSP-specific description of current service status, e.g. "Active", 
"Ceased", etc. 





regis teredlCCID 


Integrated Circuit Card ID of subscriber. 





nationalNASubscription 


Description of the subscription to a Network Access service. 





paymentDetails 


Details for payment (e.g. associated bank account, billing method 
or billing address). 





addi t i ona 1 1 PAddr e s s e s 


Additional IP addresses when CSP provides several IP addresses 
to one subscriber. 






E.2. 4 NAServiceUsage 



This structure contains the information on network access and attempted access by a subscriber. 
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Table E.3: NAserviceUsage parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


naAccessTime 


Date and time of tlie (attempted) networl< access. 


C 


naAuthID 


Logon name (username) used to obtain networl< access. 


C 


nwAccessType 


Type of networl< access attempted. If not undefined(O), this should be 
one of the types supported by the NAS. 





naStatus 


Results of the access attempt. 





interval 


Start time and end time of network access. Used only if naStatus 
indicates a success. This is also the period during which the IP 
address is assigned to this subscriber. 


c 


naDeviceld 


Information on the device used to access the service. 


c 


naNwElementID 


Network element (NAS) onto which the subscriber's device is 
connected to the service. 





naAssignedAddress 


IP address assigned by the network access service. Depending on the 
service and type of subscription this may be a fixed address (unique to 
this subscriber) or dynamic (shared among multiple subscribers), or 
accompanied by a port number where Port Address Translation is 
used. 


c 

(see note) 


location 


Location of the network access, if applicable. 





dialUpInf ormation 


Information specific to dial-up access (see table E.4). 





gprs Information 


Information specific to gprs access (see table E.5). 





octet sDownloaded 


Number of octets downloaded by the subscriber during the network 
access session. 





octetsUploaded 


Number of octets uploaded by the subscriber during the network 
access session. 





endReason 


Indication of why the network access session ended. 





subscriberlD 


Identifier for a known user of this network access. 





NOTE: This is required if tlie naStatus indicates a successful networl< access attempt. 



Table E.4: DialUplnformation parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


diallingNumber 


Telephone number used at the subscriber side for dial-up access. Used 
only if nwAccessType indicates a dial-up service. 


C 


dialledNumber 


Telephone number used at the network element side for dial-up access. 





callback 


Call back number used for dial-up access. Call back causes the call to be 
charged by the dial-up network operator to the CSP, not to the 
subscriber. 






Table E.5: GPRSInformation parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


IMS I 


IIVISI associated with the network access. 


C 


mSISDN 


IVISISDN associated with the network access. 





sgsnAddress 


IP address of the SGSN. 





ggsnAddress 


IP address of the GGSN. 





pdp- address -allocated 


PDP address allocated for the network access. 





apn 


APN of the network access. 





pdp -type 


PDP type, format as per TS 101 671 [6]. 





gPRSEvent 


GPRS event, as per 3GPP TS 33.108 [11]. 






E.2.5 NADevice 

This structure contains information on the device used by the subscriber to access the service. It is allowed to use the 
MAC address, DSL ID, or other ID as the device ID (naDeviceld). MAC addresses can often be changed. If the MAC 
address is used as the primary device ID, then naDeviceld cannot be guaranteed to be unique (two devices could have 
the same MAC address). 
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Table E.6: NADevice parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


naDeviceld 


Identifier of this device, e.g. the IVIAC address. 





description 


Human readable description of the device. 





location 


Installation address of the device, if known. 





macAddress 


MAC or ethernet address as presented to the network. 





dslID 


DSL identifier of the DSL connection to the CSP. 





subscriberlD 


Identifier for a known user of this device or equipment. 






E.2.6 NANwElement 

This structure contains information on a network access server (NAS). 

Table E.7: NANwElement parameters 



Field name 


Value 


M/C/0 
(see clause A.I .1) 


validity 


Time period during which the information given in this structure is 
or was valid. 





naNwE 1 ement I D 


A unique identifier of this network access server. 





naProviderlD 


A unique identifier of the CSP, e.g. company name or company 
registration number. 





support edAccessTypes 


The list of access types supported by this network access server. 





location 


Installation address of this network access server, if known and 
meaningful. 






E.2.7 NABillingDetails 

The NABillingDetails structure gives information about the network access subscriber's billing history for a particular 
subscription. The parameters are as follows. 

Table E.8: NABillingDetails parameters 



Field name 


Value 


M/C/0 
(see clause A.I. 1) 


subscriberlD 


Unique identifier for this subscriber. 





servicelD 


Identifier for the service e.g. account plan name. 





billingAddress 


The billing address for this subscription. 





billingldentif ier 


A unique identifier for billing purposes. The format of this field is for 
CSPs to determine. 





billingRecords 


A sequence of billing records, one for each payment by the subscriber 
on this subscription - see clause B. 2.3.1 . 





naTransactionID 


Unique reference for this transaction/billing record, to be defined on a 
national basis. 





naTransactionStatus 


Status of the transaction (i.e. "declined", "succeeded", etc.), to be 
defined on a national basis. 
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E.3 ASN.1 definitions for network access services 



NetworkAccessRecord: := 

{ 

naSubscriber 


= CHOICE 


[1] NASubscriber, 


naServiceUsage 


[2] NAServiceUsage, 


naDevice 


[3] NADevice, 


naNetworkElement 


[4] NANwElement, 


naBillingDetails 

} 


[5] NABillingDetails, 



Definitions of Network Access Subscriber Data 



NAProviderlD ::= UTFSString 



NAAuthID ::= UTFSString 



NaSubscriberlD ::= UTFSString 



NASubscriber : : = SEQUENCE 

-- Generic information on a service subscriber, supplemented with information specific to 
-- network access services. 

{ 

validity [1] TimeSpan OPTIONAL, 

subscriberlD [2] NaSubscriberlD OPTIONAL, 

-- Unique identifier for this subscriber, e.g. account number 
naSubscriptions [3] SEQUENCE OF NAServiceSubscription OPTIONAL, 

-- List of all known services subscribed to by this user 
allocatedDevicelDs [4] SEQUENCE OF NADeviceld OPTIONAL, 

-- List of all known devices allocated to this user. 
subscriber [5] GenericSubscriberlnfo OPTIONAL , 

-- Name, address and other generic subscriber information 



NAServiceSubscription : : = SEQUENCE 

-- Description of the subscription to a Network Access service 

{ 

validity [1] TimeSpan OPTIONAL, 

naServicelD [2] UTFSString OPTIONAL, 

-- Identifier for the service, e.g. account plan name. 
naProviderlD [3] NAProviderlD OPTIONAL, 

-- Unique identifier for the provider of the service, e.g. company name 
naAuthID [4] NAAuthID OPTIONAL, 

-- Unique identifier for this subscription, e.g. logon name 
options [5] UTFSString OPTIONAL, 

-- Human readable text with restrictions or options to the subscription 
installationAddress [6] Addresslnformation OPTIONAL, 
fixIpAddress [7] IPAddress OPTIONAL, 

-- fix assigned IP address 
imsi [S] IMSI OPTIONAL, 

allocatedDevicelDs [9] SEQUENCE OF NADeviceld OPTIONAL, 

naServiceStatus [10] UTFSString OPTIONAL, 

-- CSP-specific description of current service status, e.g. "Active", "Ceased", etc. 

registeredlCCID [11] UTFSString OPTIONAL, 

nationalNASubscription [12] NationalNASubscription OPTIONAL, 

paymentDetails [13] PaymentDetails OPTIONAL, 

additionallPAddresses [14] SEQUENCE OF IPAddressSetOrRangeOrMask OPTIONAL 



NationalNASubscription : : = SEQUENCE 

-- Description of the subscription to a Network Access service 

{ 

countryCode [1] UTFSString {SIZE{2)), 

-- see comment in NationalRequestParameters 
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-- Definitions of Network Access Service Usage 



NAServiceUsage : : = SEQUENCE 

{ 

naAccessTime [1] GeneralizedTime OPTIONAL, 

-- Time of connection to the NAS 
naAuthID [2] NAAuthID OPTIONAL, 

-- Username used to obtain network access 
nwAccessType [3] NwAccessType OPTIONAL, 

-- Type of network access attempted. If not undefined (0) , this should be one of the types 

-- supported by the NAS {identified below by naNwElementID) 
naStatus [4] ENUMERATED 

{ 

unknown { ) , 
succeeded (!) , 

-- Authentication OK and access granted 
£ailed{2) , 

-- Authentication failure {wrong credentials or time out) 
rejected (3) , 

-- Rejected by the CSP {e.g. usage limits exceeded) 

} OPTIONAL, 

interval [5] TimeSpan OPTIONAL, 

-- Start time and end time {duration) of network access. 
naDeviceld [6] NADeviceld OPTIONAL, 

-- Device used to access the service 
naNwElementID [7] NANwElementID OPTIONAL, 

-- Network element {NAS) onto which the naDevice is connected 
naAssignedAddress [8] SEQUENCE OF NAAssignedAddress OPTIONAL, 

-- IP address assigned by the network access service. May be fixed or dynamic 
location [9] Location OPTIONAL, 

-- Location of the access {for e.g. GPRS handsets) 
dialUpInformation [10] DialUpInf ormation OPTIONAL, 
gprslnformation [11] Gprslnformation OPTIONAL, 

octetsDownloaded [12] INTEGER OPTIONAL, 
octetsUploaded [13] INTEGER OPTIONAL, 
endReason [14] NAEndReason OPTIONAL, 

subscriberlD [15] NaSubscriberlD OPTIONAL 

-- Identifier for a known user of this network access 
J 

NAEndReason : : = ENUMERATED 

{ 

unknownReason { ) , 
timeout {1) , 
userOisconnect {2) , 

-- e.g. user logs off 
networkoisconnect {3) , 

-- e.g. user's time/credits have been used up 
networkError {4) , 



} 



NwAccessType ::= ENUMERATED 

{ 

undef ined{0) , 
dialUp{l) , 

-- DialUp access 
xDSL{2) , 

-- DSL access 
cableModem{3) , 

-- Cable access 
IAN {4) , 

-- LAN access 
wirelessLAN{5) , 

-- Wireless LAN access {e.g. hotspot) 
wimax { 6 ) , 
mobilePacketData{7) , -- Network access over GSM/3GPP GPRS, UMTS, etc. 
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DialUpInformation : 


= SEQUENCE 




t 


diallingNiunber 


[1] 


Party-Number 


OPTIONAL, 




-- Telephone 


number 


used for dial-up access 




dialledNiunber 


[2] 


PartyNumber 


OPTIONAL, 




callback 


[3] 


PartyNumber 


OPTIONAL, 


} 


-- Call back 


number 


used for dial-up access 



Gprslnformation ::= SEQUENCE 




1 

IMS I 


[1] 


IMSI OPTIONAL, 


mSISDN 


[2] 


PartyNumber OPTIONAL, 


sgsnAddress 


[3] 


SEQUENCE OF IPAddress OPTIONAL, 


ggsnAddress 


[4] 


IPAddress OPTIONAL, 


pDP- address -allocated 


[5] 


IPAddress OPTIONAL, 


aPN 


[6] 


UTF8String OPTIONAL, 


pDP-type 


[7] 


OCTET STRING {SIZE{2)) OPTIONAL, 


-- format as per TS 101 


671 


[6] 


gPRSEvent 


[8] 


GPRSEvent OPTIONAL 


-- format as per 3GPP TS 33.108 [11] 


-- Tag [9] was used in 
} 


the past and shall not be reused. 



GPRSEvent : : = ENUMERATED 

{ 

pDPContextActivationd) , 






pDPContextDeactivation (4) , 




gPRSAttach{5) , 




gPRSDetach{6) , 




locationlnfoUpdatedO) , 




-- sMS ommited from 3GPP TS 33.108 


[11] , 


pDPContextModificationdl) , 




servingSystem{12) , 

} 





Definitions of Networ]^ Access Device 



NADeviceld 



UTF8String 



NADevice 



SEQUENCE 



naDeviceld [1] NADeviceld OPTIONAL, 

-- Identifier of this device. 
description [2] UTF8String OPTIONAL, 

-- Human readable description of device 
location [3] Location OPTIONAL, 
macAddress [4] OCTET STRING {SIZE (6)) OPTIONAL, 

-- MAC or ethernet address 
dslID [5] UTF8String OPTIONAL, 

imei [S] IMEI OPTIONAL, 



subscriber ID 



[7] NaSubscriberlD OPTIONAL 



IMEI : 


:= OCTET STRING {SIZE{8)) 




-- 


format as per 3GPP TS 09.02 


[8] 


-- 


NOTE: When comparing IMEIs, 


an IMEI can be considered "equal to" the requested IMEI even 


-- 


if the checlcsum or software 


version digits are different or not present. 



IMSI ::= OCTET STRING {SIZE {3.. 8)) 

-- format as per 3GPP TS 09.02 [£ 



Definitions of Message Networlc element 



NANwElementID ::= UTF8String 
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NANwElement : : = SEQUENCE 




-- In this context, the 

{ 

validity 


network element is more commonly referred to as NAS 


[1] TimeSpan OPTIONAL, 


-- Period for which 


this interval is valid 


naNwElementID 


[2] NANwElementID OPTIONAL, 


-- Unique ID of this NAS {Network Access Server) 


naProviderlD 


[3] NAProviderlD OPTIONAL, 


-- Unique identifier of 


the provider managing this NAS. 


supportedAccessTypes 


[4] SEQUENCE OF NwAccessType OPTIONAL, 


location 

} 


[5] Location OPTIONAL, 



IPAddress ::= CHOICE 

{ 

iPv4BinaryAddress 




[1] OCTET STRING {SIZE{4)), 


iPv6BinaryAddress 


[2] OCTET STRING {SIZE{1S)), 


iPTextAddress 

} 


[3] lABString {SIZE {7 . . 45 ) ) , 



NAAssignedAddress ::= SEQUENCE 




t 

addressSetOrRangeOrMa 


sk 


[1] IPAddressSetOrRangeOrMask OPTIONAL, 


portNiunber 




[2] INTEGER OPTIONAL, 


-- populated with 


the outbound port number 


addressType 

{ 

unknown { ) , 




[3] ENUMERATED 






internal {1) , 






external {2) , 






} OPTIONAL, 






assignedTime 




[4] TimeSpan OPTIONAL, 


destinationAddress 




[5] IPAddress OPTIONAL, 


-- used in cases 


where 


a single external IP/port pair is translated to multiple internal 


-- IP/port pairs. 


with 


the destination IP/port used to multiplex them 


destinationPort 




[6] INTEGER OPTIONAL 


-- used in cases 


where 


a single external IP/port pair is translated to multiple internal 


-- IP/port pairs, 
} 


with 


the destination IP/port used to multiplex them 



{ 


iddressSetOrRangeOrMask : 


= CHOICE 


set 


[0] 


SEQUENCE OF 


IPAddress, 




range 


[1] 


IPRange, 




} 


mask 


[2] 


IPMask 





IPRange : : = SEQUENCE 

-- Things like 172.16.10.0/26 



prefix 
subnet length 



[0] IPAddress, 

[1] INTEGER {1. .128) 



IPMask : : = SEQUENCE 

-- Things like 172.16.10.0/255.255.255.240 



base 
mask 



[0] IPAddress, 
[1] IPAddress 
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NABillingDetails ::= SEQUENCE 

{ 

subscriberlD [1] NaSubscriberlD OPTIONAL, 

servicelD [2] UTFSString OPTIONAL, 

billingAddress [3] ContactDetails OPTIONAL, 

billingldentifier [4] Billingldentif ier OPTIONAL, 

billingRecords [5] SEQUENCE OF BillingRecords OPTIONAL, 

naTransactionID [6] UTFSString OPTIONAL, 

-- Unique reference for this transaction/billing record 

-- Details to be defined on a national basis 
naTransactionStatus [7] UTFSString OPTIONAL 

-- Status of the transaction {i.e. "declined", "succeeded" etc.) 

-- Details to be defined on a national basis 



end of RDMessage 
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E.4 Schematic view of ASN.1 definitions 

networkAccess 
naSubscrlber 

validity 
subscriberlD 
naSubscriptions 
^ NAServiceSubscription 

- validity 

- naServicelD 

- naProviderlD 

- naAuthID 

- options 

- installationAddress 

- fixIpAddress 

- imsi 

- allocatedDevicelDs 

- naServiceStatus 

- registeredlCCID 

- nationalNASubscription 

- paymentDetails 
^ additionallPAddresses 

allocatedDevicelDs 
subscriber 
- naServiceUsage 
naAccessTime 

- naAuthID 

- nwAccessType 
naStatus 
interval 
naDeviceld 
naNwE 1 ement I D 
naAs s ignedAddres s 
location 

- dialUpInformation 

- gprslnformation 

- octetsDownloaded 

- octetsUploaded 
^ subscriberlD 

naDevice 

naDeviceld 

description 

location 

macAddress 

dslld 

imei 

subscriberlD 
naNetworkElement 

validity 

naNwElementID 

naProviderlD 

- supportedAccessTypes 
location 

'- naBllllngDetails 
subscriberlD 
servicelD 
billingAddress 
billingldentif ier 
billingRecords 
naTransactionID 
naTransactlonStatus 

NOTE: This figure slnould be regarded only as an aid to understanding. In the event of a discrepancy between this figure and 
the text of the ASN.1 specification the ASN.1 specification is the leading one. 

Figure E.1 : Schematic representations of thie major ASN.1 structures for networit access services 
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Annex F (informative): 

Basic set of search routines for Retained Data 

F.1 Example set of search routines 
F.1.1 Introduction 

The purpose of this informative annex is to give some guidance for implementation of specific search routines. 

The following set of search routines are given as guidelines. It is a national option to which extent this set is used and 
possibly extended with additional search cases. 

This annex specifies search cases for retrieval of top level record types according to the table F. 1 . 



F.1 .2 Summary of search case 



Table F.1 : Summary of search case 



Record type 


Clause(s) 


Comments, search parameters 


Any records 






timeSpanT1-T2 




For any search, a time span relating to time of retention is to be 
provided. 


Telephony Record 






telephonySubscriber 


F.2.1 


Subscriber ID, name, address, phone number (originating/terminating), 
national registration identifier. 


telephonyBillingDetails 


F.2.2 


Subscriber ID. 


telephonyServiceUsage 


F.2.3 


Phone number (originating/terminating), device ID (IIVIEI), location 
(originating). 


telephonyDevice 


- 


Implicit through service usage. Since this is CPE, the identity of which 
will not be known except in conjunction with usage, it is not relevant to 
query about it independently. 


telephonyNetworkElement 


F.2.4 


Network element ID, location. 


Message Record 






msgSubscriber 


F.3.1 


Subscriber ID, name, address, message store ID, national registration 
identifier. 


msgServiceUsage 


F.3.2 


Subscriber ID, sender address, recipient address. 


Network Access Record 






naSubscriber 


F.4.1 


Subscriber ID, name, address, NA device id, national registration 
identifier, location (of access point), MAC address, DSL ID. 


nsServiceUsage 


F.4.2 


Device ID, location (of access point), MAC address, DSL ID. 


naDevice 


- 


Implicit through service usage or subscriber data. Since this is CPE, the 
identity of which will not be known except in conjunction with usage, it is 
not relevant to query about it independently. 


naNetworkElement 


- 


Implicit through service usage. Since this is equipment in the network, 
which is not specific to any individual user, it is not relevant to query 
about it independently. 



F.1. 3 Subscriber records 

The subscriber records are retrieved per service by providing the appropriate service-specific subscriber record type, 
filled in with applicable search parameters. 
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F.2 Telephony data 
F.2.1 Telephony subscriber 



Search parameter 


Result 


subscriberld 


Telephony subscriber record with matching subscriber id is 
returned. 


regis teredNumber 


Subscriber record for telephony service with matching phone 
number is returned. 


Name, address 


Subscriber record(s) with matching subscriber name and/or 
address are returned. 


nationalRegistration/identif icationNumber 
(any service) 


Subscriber record with matching national registration id are 
returned. 



F.2.2 Telephony billing details 

The billing details for a specific telephony subscriber will be returned. 



Search parameter 


Result 


subscriberld (telephony) 


Billing records for the supplied subscriber id will be returned. 



F.2.3 Telephony service usage 



Records of telephony service usage will be returned through search on one or more of the following parameters in 
par ty Information : 



Search parameter 


Result 


partyNumber 


All telephony service usage records containing the provided party 
number (originating/terminating) will be returned. 


devicelD 


All telephony service usage records containing the provided device 
id (originating/terminating) will be returned (see note). 


Location 


All telephony service usage records made from the provided location 
(originating) will be returned. 


NOTE: In practical use the type of device id will be an IIVIEI. 



F.2. 4 Telephony network element 



Searches on telephony network elements are relevant for finding where a certain cell-id is located or which cell-ids are 
located in a certain area at some given time. Search parameters are one of: 



Search parameter 


Result 


telephonyNetworklD 


Entry of a network element ID will return the record containing cell 
information for this ID (see note 1). 


cellinf ormation (Location data) 


Entry of location data will return network element IDs within the 
specified area (see note 2). 


NOTE 1 : It ought to be possible to use wildcarding for network ID, which would return a set of matching records, 
which subsequently may be analyzed to select those which are located within an area of interest. 

NOTE 2: This assumes that the input parameters can be given according to a format specifying an area and that 
network elements are searchable based on a delimited area. 
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F.3 Messaging data 
F.3.1 Message subscriber 



Search parameter 


Result 


subscriberld 


Messaging subscriber record with matching subscriber id is 
returned. 


msgStoreld 


Subscriber record for messaging service involving the supplied 
storage id (mailbox id) is returned. 


Name, address 


Subscriber record{s) with matching subscriber name and/or 
address are returned. 


nationalRegistration/identif icationNumber 


Subscriber record with matching national registration id is 
returned. 



F.3.2 Message service usage 



Usage records for message services may be found through the following parameters of msgTransmission. 



Search parameter 


Result 


subscriberiD (for messaging) 


Service usage records for the given subscriber ID will be returned. 


s ende r Addr e s s 


Usage records, which contain a sender address matching the entry, 
will be returned. 


Recipients 


Usage records, which contain a recipient address matching the 
entry, will be returned. 



F.4 Network Access data 



F.4.1 NA subscriber 



Search parameter 


Result 


subscriberld 


Subscriber record with matching subscriber id is returned. 


Name, address 


Subscriber record(s) with matching subscriber name and/or 
address are returned. 


nat ionalRegi St rat ion/ident if icationNumber 


Subscriber record with matching national registration id is 
returned. 



In addition to this, the following parameters in allocatedDevicelDs may be used to retrieve network access subscriber 
data: 



Search parameter 


Result 


naDeviceld 


Subscriber record containing the given device ID will be returned 
(see note). 


Location 


Subscriber record containing the given location will be returned. 


macAddress 


Subscriber record containing the given MAC address will be 
returned. 


dslID 


Subscriber record containing the given DSL ID will be returned. 


naAs s ignedAddres s 


Usage records containing the given IP address will be returned. 


NOTE: It is assumed that a network access device (typically a DSL or cable modem) relates to a specific 
subscribed access service. 
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F.4.2 NA service usage 



Searches for NA service usage can be made based on the user device, as recorded in naDevice: 



Search parameter 


Result 


naDeviceld 


Usage records containing the given device ID will be returned. 


Location 


Usage records containing the given location will be returned. 


macAddress 


Usage records containing the given MAC address will be returned. 


dslID 


Usage records containing the given DSL ID will be returned. 
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Annex G (informative): 
Examples of search routines 

G.1 Introduction 

This annex gives extra details for how to implement a number of search routines described in annex F. 

Each clause takes an example request from annex F, and shows how it would be constructed using this handover 
standard. The example shows the inputs (listed in annex F), and a diagram representing the PDU for the request 

message. 



G.2 Example for telephony subscriber query in 
clause F.2.1 

This clause describes how to construct the following telephony subscriber request, described in clause F.2.1. 

The specific question is: Please provide data for subscriptions with telephone number 0123456789, which were started 
in the time span between 1 August 2008 and 15 September 2008. 



Request Parameter 


Value 


registeredNumber 


Subscriber record for telephony service with matching phone number 
is returned. 


timeSpan 


A range of times for the start of the subscription. 
In cases where endTimes are provided as part of a constraint, a 
non-populated value in a record can be considered to be greater than 
the specified endTime in the constraint. 



RetainedDataMessage 
|- retalnedDataHeader 

I ^ {header information, as described in clause 6.1) 
^ retainedDataPayload 

^ requestMessage 

|- requestPriority = NORMAL {per national implementation) 
'- requestParameters 
- equals 

'- telephonyRecord 

^ telephonySubscriber 

^ subscribedTelephonyServices 

I- registeredNumber = 0123456789 
great erThanOrEqualTo 
I- telephonyRecord 

'- telephonySubscriber 

^ subscribedTelephonyServices 
^ timeSpan 

L startTime = 20080801000000Z 
L lessThanOrEqualTo 
^ telephonyRecord 

^ telephonySubscriber 

^ subscribedTelephonyServices 
^ timeSpan 

L StartTime = 20080915235959Z 

Figure G.I : Example for telephony subscriber query 
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G.3 Example for telephony service usage query in 
clause F.2.3 

This clause describes how to construct the following telephony subscriber request, described in clause F.2.3. 

The specific question being asked is: Please provide service usage records for phone number 0123456789 for calls, 
which were initiated from that number between 5 September 2008 and 15 September 2008. 



Request Parameter 


Value 


partyNumber 


Telephone number of interest in the call. 


partyRole 


Role (originating or terminating) of the telephone number specified. To 
request all calls involving the given number, regardless of its role, this 
parameter can be omitted. 


timeSpan 


A range of times for the start of the call. 



RetalnedDataMessage 
|- retalnedDataHeader 

I ^ {header information, as described in clause 6.1) 
^ retainedDataPayload 
'- requestMessage 

|- requestPriority = NORMAL {per national implementation) 

'- requestParameters 

- equals 
^ telephonyRecord 

^ telephonyServiceUsage 
^ partylnformation 

|- partyNumber = 0123456789 

^ partyRole = {=originating- Party) 

- greaterThanOrEqualTo 
^ telephonyRecord 

'- telephonyServiceUsage 
^ communicationTime 
^ timeSpan 

L startTime = 20080905000000Z 
L lessThanOrEqualTo 
^ telephonyRecord 

^ telephonyServiceUsage 
^ communicationTime 
^ timeSpan 

L StartTime = 20080915235959Z 

Figure G.2: Example for telephony usage query 

NOTE: Regarding the response records returned in this example: provided a record meets the criteria in the 
request, then both the begin- and end-time can be included in the response (if they are part of the 
communication record). 
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Annex H (informative): 

Further information on data categories 

H.1 General 

There is a distinction between data categories that are based on user activity (such as Usage data) and those that are 
independent of user or network activity - information not generated or processed by network elements (such as 
Subscriber or Network Element information). 

The distinction in type of request is made to allow national adaptation of the present document. The distinctions can be 
necessary for different levels of authorizations and/or providers. The distinction for different levels of authorizations 
and/or providers can also be met by national adaptation of the field delivered in the reply. A single request can contain a 
combination of types (e.g. a, b and c for a generic activity request). 

EXAMPLE: A Subscriber Data Request even within one nation can have different levels of authorizations: 
billing information and/or a PUK-code will not be part of a "standard" request. 



H.2 Further information on subscriber data 
H.2.1 Subscriber data requests 

The following records could be used to make a subscriber data request: 

a) Name. 

b) Address. 

c) Postcode (with street number). 

d) National ID no. 

e) Birth date. 

f) Service identifier (e.g. phone/network number, email address, IP-addresses, device-ID, log on names, etc.). 

g) Location. 

Ad g): Discussion on prepaid identification. 

In order to be selective a combination of entries can be made. The allowed single and combined entries are a national 

issue. 
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H.2.2 Generic subscriber data records 

This clause contains the Subscriber Data Reply information. As this information is not derived from network 
information it can be structured more open and might not be addressed in the network based clauses. 

The reply to a subscriber data request will depend on the structure and the fields available in the CSP's subscriber 
database and the national juridical framework. 

In general the reply contains: 



a) 


Names. 


b) 


Addresses. 


c) 


Birth dates. 


d) 


Service identifier. 


e) 


Authentication. 


f) 


Applicable services. 


g) 


Applicable supplementary services 


h) 


Service association. 


i) 


Timestamp. 



Ad a): Multiple names, addresses and birth dates can be available for the subscriber, billing and phonebook 
information. 

Ad d): The service identification can be the phone numbers, email addresses, permanent IP-addresses, log on names, 
conference call identifier, etc. 

Ad e): Depending on national regulations, no authentication information will be given, type will be given (credit card, 
passport etc.) or details will be given (credit card number, passport number, etc.). 

Ad f): The applicable services can be given as type of subscriptions and as a list of applicable network services. (For 
example a mobile subscription can be called "Budget U" and can give access to all GSM services excluding 
GPRS and UMTS, also a limitative Ust GSM, GPRS, UMTS-PS, and UMTS-CS could be given.) 

Ad g): The entry can be associated with CSP activated services like call bearing, ex- number, carrier pre-select, 
0800/0900 number, multiple SIM, PUK-code, etc. 

Ad h): A service identifier is associated with a specific service or tele service (for example a MS-ISDN can be 

associated with a service like GSM and/or UMTS and within GSM it can also associate to the tele service 
voice, fax or data). 

H.2.3 Service Specific Subscriber Reply Data 

a) Service identifier. 

b) Applicable services. 

c) Applicable supplementary services. 

d) Service association. 

e) Timestamp. 
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H.3 Further information on usage data 
H.3.1 Usage requests 

Usage requests would typically be based on: 

a) Network addresses (for example IMSI, email, IP-address). 

b) User addresses (for example (MS-) ISDN, email, URI). 

c) Hardware address (device-ID for example IMEI, MAC). 

d) Location (for example CelllD). 

H.3. 2 Usage data categories 

Usage data can be broken down into the following sub-categories: 

a) Usage: Traffic data. 

b) Usage: Traffic data related information. 

c) Usage: Communication independent user activities. 

d) Usage: Network activity data. 

H.3.3 Usage: Traffic Data (Reply) 

In general the reply contains: 

a) Network addresses. 

b) User addresses. 

c) Communication entity. 

d) Tele-/bearer service used. 

e) Supplementary service. 

f) Timestamp. 

Ad c): The association of the network/user address with the role in the communication (A, B, C-address, 
FROM/TO/CC/BCC, etc.). 

H.3. 4 Usage: Traffic Data related information (Reply) 

In general the reply contains: 

a) Hardware address. 

b) Location. 

c) Timestamp. 
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H.3.5 Usage: communication independent user activities (Reply) 

In general the reply contains: 

a) User associated log on/off. 

b) (de)activation of supplementary services. 

c) Pre paid updates. 

d) Timestamp. 

H.3.6 Usage: network Activity Data (Reply) 

In general the reply contains: 

a) Equipment/Network associated log on/off. 

b) Roaming information. 

c) Timestamp. 

H.4 Further information on network element data 
H.4.1 Network element requests 

Network element requests would typically be based on: 

a) Location. 

b) Network element. 

Ad a): The association between a location in WGS84 or Postcode to the likely CelllDs can be requested. 
Ad b): The association of for example between a CelllD and its location and direction can be requested. 

H.4.2 Network Configuration Data Reply Data 

In general the reply contains: 

a) Location association with network elements. 

b) Network element association with location. 

c) Timestamp. 
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Annex I (informative): 
Manual techniques 

Manual techniques can include: 

• Use of phone, fax or email for HI- A or HI-B. 

• Use of physical storage media (e.g. DVD) for HI-B. 
For all manual uses, the following principles are recommended: 

• The message flows (clause 5) should be broadly followed although acknowledgements may be unnecessary or 
not practical. 

• It is strongly recommended that the content of the messages should follow the messages defined in clause 6. 

• Lower layers (encoding, transport, etc.) (clause 7) in general would not be followed. Where appropriate, 
consistent encoding schemes are recommended. 
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Annex J (informative): 

Informative mapping of data fields to the EU Data Retention 

Directive 

Table J.l provides an informative mapping of data fields to the EU Data Retention Directive [1]. 

Table J.1 : Mapping of data fields to the EU Data Retention Directive 



Table 


Field name(s) 


Clause of Article 5 that explicitly mentions these fields 


A.2.10 


Name, ContactDetails 


1.a.1.ii/1.a.2.iii/1.b.1.ii/1.b.2.ii 


A.2.11 


Name, ContactAddress 


1.a.1.ii/1.a.2.iii/1.b.1.ii/1.b.2.ii 


B.2.5 


Partylnformation, 


1.a.1.i/1.b.1.i/1.e.1.i/1.e.2.i 


B.2.5 


Communicationlime 


1.C.1 


B.2.5 


Communicationlype 


1.d.1 


B.2.5 


BearerService 


1.d.1 


B.2.6 


PartyRole, PartyNumber 


1.a.1.i/1.b.1.i/1.e.1.i/1.e.2.i 


B.2.6 


DevicelD 


1.e.2.iii/1.e.2.v 


B.2.6 


Location 


1.f.1 


B.2.7 


DevicelDType, TelephonyDevicelD 


I.e. 2. ill/ 1.e.2.v 


B.2.8 


TelephonyNetworklD, Celllnformation 


1.f.2 


B.2.9 


GlobalCelllD, GsmLocation, UmtsLocation 


1.f.2 


C.2.1 


Subscriber 


1.a.2.iii/1.b.2.ii 


C.2.2 


Aliases 


1.a.2.i 


C.2.3 


Datelime 


1.c.2.ii 


C.2.3 


SenderAddress 


1.a.2.i 


C.2.3 


Recipients 


1.b.2.i 


C.2.3 


ClientlD 


1.d.2 


C.2.4 


Datelime 


1.c.2.ii 


C.2.4 


SenderAddress 


1.a.2.i 


C.2.4 


Recipients 


1.b.2.i 


C.2.4 


ClientlD 


1.d.2 


E.2.1 


Subscriber 


1.a.2.jii 


E.2.2 


NaAuthID 


1.c.2.i 


E.2.3 


AccessTime 


1.c.2.i 


E.2.3 


NaAuthID 


1.c.2.i 


E.2.3 


Interval, naAssignedAddress 


1.c.2.i 


E.2.3 


naDevice 


1.e.3.ii 


E.2.3 


DiallnNumber 


1.e.3.i 
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Annex K (informative): 

Single versus multi-part deliveries 

K.1 General 

Subject to national agreement, the multi-part delivery of results may be used replacing the default single shot delivery 
(clause 5. 1 .7). In clause 5.2.3 the option of delivering results of an RD query in multiple parts is described. When 
multi-part is set as possible national delivery option, a CSP may promptly send data that are at hand and follow up with 
data that takes longer to collect, if and when available. There is however no rule for when to apply multi-part deliveries. 
In absence of such guidance it is likely that all deliveries will be made in multiple parts, since additional data might 
always be available. It is also undefined when to send the final message, so the transfer will tend to be open-ended. 

In this annex there is an elaboration of criteria for when to apply multi-part deliveries. 



K.2 Criteria for multi-part delivery 

The maximum time allowed for transfer of retained data from a network element to a storage from which it can be 
retrieved is called "latency time" (TL). This time may vary, depending on type of network element and operating 
conditions. An upper limit for TL under different conditions may be set in national requirements. When a request for 
retained data is made, the related time span is specified as T1-T2. This means that retained data for all events that have 
occurred during the time span between Tl and T2 and meet the search criteria are to be sent to the receiving authority. 
T2 will be less than or equal to the time of the request, TR (see however clause K.3). If TL is larger than the difference 
between TR and T2, some retained data from before T2 can be expected to be collected later than TR, such that 
multi-part delivery will be necessary, if available data are sent promptly. At a time T2H-TL, it can be assumed that all 
events have been collected. 

Figures K.l and K.2 illustrate the conditions for single- vs multi-part deliveries. 



f. I 




TL 
Figure K.l : TR occurs later than T2+TL and thus a single part delivery can be applied 



f. 




Figure K.2: TR occurs earlier than T2+TL, so a multi-part delivery should be applied 
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In figure K.2, the last delivery should be sent at time T2+TL, indicating that transmission is complete. 

NOTE 1 : A CSP may choose to make multi-part deliveries in a sequence in order to break up large transmission 
volumes into more manageable parts. 

NOTE 2: It may be agreed to have a single delivery when all data are available, rather than applying multiple 
deliveries. 



K.3 Subscriptions into the future 



It is conceivable to make T2 larger than TR, i.e. subscribe to delivery of retained data into the future. This is a subject 
for national preferences. A LEA may also choose to repeat the request at certain intervals until an investigation has been 
closed. 
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